Using Bots to Solve Problems

Objective: Learn to systematically approach problems in order to more quickly break them down for automation opportunities

When evaluating an opportunity for automation, in its simplest form, a bot is designed to help solve problems. While that seems simple to say, often times developers (new and old) can become overwhelmed with a laundry list of requirements thrown at them all at once, whether that be in the form of a poorly documented process design document, or by way of a recorded screen share that quickly rattles through any number of steps of a process which may or may not include the specific detailed requirements for each step. With that said, it’s important to highlight that most business/process problems can be broken down into 3 core tenets of problem-solving.

Let’s look at each of the tenets for using bots to solve problems. This involves understanding, dissecting, and communicating processes.

1. Sequence

Sequence is the order in which steps must occur to accomplish a goal. Everything in an RPA automation happens in a specific order for a specific reason. In this way, sequence is very important as we think through problem solving and solution design. If steps are skipped, or done out of order, then the outcome may not be as intended. Take an example we’re all familiar with: making coffee in a coffee pot.

1. Put in a filter

2. Pour in ground coffee

3. Fill the coffeemaker with water

4. Press the button to start brewing.

If I left out step 1, I’d end up with coffee grounds in my coffee. If I skipped step 2, I’d end up with hot water…not coffee. As you work to define processes targeting for RPA automation, be sure that they are documented in a way which clearly calls out the sequence in which the steps need to occur to reach the desired outcome.

2. Selection

Selection is the process of taking action (or not) based on the evaluation of a condition. There will be times in our business processes where we optionally perform actions based on the evaluation of criteria/conditions. For humans, we’re able to very quickly make those kind of decisions and react accordingly. For a bot, we need to make sure that such logic is explicitly built out so the bot is flexible enough to appropriately handle different situations. Take an example of checking email:

1. Go to gmail.com

2. If the login page appears then

   1. Enter login credentials

   2. Click submit

3. Start looping through today’s emails

For a human, that makes sense - “Oh I must not be logged in. Maybe my session expired.” For a bot (who may be expecting a full page of emails to appear no matter what), that logic needs to be built in so that the bot knows how to appropriately handle situations where the data/application does not always look the way that it did with the “happy path” execution.

3. Repetition

Repetition is the determination of how many times, or under what conditions, a process should continue to execute. Most business processes in an organization include tasks that must be done “for each row in a spreadsheet” or “for each file in a folder.” Those “for each” kind of statements represent a task that is done in repetition. The task that is repeated could be a simple as a single action to move a file, or as complex as filling out data in 2-3 other systems and making updates to the original file itself. Either way, repetition is how we would handle the “for how many times” kind of logic. Consider the example of pulling weeds in a garden. To pull weeds I would:

1. Grab my bucket

2. Find my gloves + shovel

3. For each weed:

   1. Find a weed

   2. Use my shovel to dig down to root

   3. Extract the weed

   4. Put the weed in the bucket for disposal

4. Put my bucket/gloves/shovel away

Notice in our example that some steps only had to be done once. Grabbing the bucket and finding gloves/shovel were operations that only had to be done a single time. The for-each-weed logic would repeat for every weed in the garden until all had been addressed. In this same way, when capturing requirements for a bot build, it’s important to understand how many times specific actions should occur, as well as how often.

Now let’s have you go a little deeper into these concepts.

To Do

Take a look at the following blog post which reiterates and expands on several of these topics: Learning to Think Like a Developer

Watch the video: What Can Bots Actually Do?

This walks through the process of understanding what bots are capable of, and how they can tie together disparate systems and applications.

Check out the module ‘Identifying Use Cases for Creating Bots’ in the Getting Started with RPA Learning Trail on Automation Anywhere University

You’ll find it on the right hand side of that page. It will help you understand what makes for a great RPA use case so that you can easily identify automation opportunities.

Summary

Breaking down automation opportunities with appropriate problem solving techniques can be the difference between a project which falls flat or an initiative the flourishes. For some, this may have been putting some language to things they were already practicing or well aware of. For others, you may find that this language can help give structure and framework to conversations with business analysts and process owners who may be communicating their automation needs in a challenging way. Regardless, take these 3 tenets into consideration as you start to plan, execute, and deliver your next bot build. For more information on ‘Using Bots to Solve Problems,’ check out the Resources column to the right.

Resources

Tutorials

Build a Bot That Uses a Desktop Application

See how easy it is to build a bot that can interface with applications on your very own desktop.

Training

Business Analyst Learning Trail

Learn how to analyze business processes and introduce RPA into your organization

Blog Posts

7 Habits of Highly Effective RPA Teams

Learn the traits of effective RPA teams and why those traits enable their success.

Myth: RPA for Developers Only? A Non-developer’s Attempt to Build a Bot

Is RPA development only for those with a background in software development? A marketing team’s perspective.

Reference Items

See how customers have used RPA

Check out case studies to see where customers have used RPA, and the benefits they’ve realized.