U.S. flag

An official website of the United States government

Dot gov

Official websites use .gov
A .gov website belongs to an official government organization in the United States.


Secure .gov websites use HTTPS
A lock () or https:// means you’ve safely connected to the .gov website. Share sensitive information only on official, secure websites.


  1. Home
  2. Defense Acquisition Magazine
  3. The Next Revolution

The Next Revolution

The Next Revolution

John Lockwood

The Bots are coming. No, it’s not the new “Terminator” movie or an update of “I, Robot,” but the next software tool coming to an agency near you. These Bots won’t take over the world, but they will help your agency do its job. Have you or your staff ever been overwhelmed with too much mundane, repetitive work? Has that work prevented you from getting to the important, creative and analytic work that could significantly help your organization? Well, Bots are here to help.

What is a Bot? Bot is short for Robotic Process Automation (RPA), which uses software to automate and, in many cases, exactly replicate with computer software what a human does. Imagine being able to automate the task of manually entering data fields from a spreadsheet to a software application, saving yourself time and allowing you to get to the important tasks on your to-do list. Not only do Bots free up humans for more important tasks, but they also may perform the process faster, more accurately and at any time during the day or night. Bots can help out in areas such as purchasing, personnel on-boarding/off-boarding, inventory reconciliation, help desk, fraud prevention, information technology configuration, filling out forms, auditing and many more areas, saving thousands of hours of work.

Let’s talk about how the Bots work. There are three software elements that go into a Bot; a development tool, a Bot that runs the process, and a management tool that schedules the Bot.

First, the development tool. Bots don’t just appear out of nowhere; someone needs to create them. That’s what our developers do. We see them more as builders than developers, due to the hands-on nature of their work. The builders use a software development tool to tell the Bot what steps to follow to complete the process. Think of it as replicating the manual process for the Bot. Once this is done, the built process is transferred to the actual Bot that will run the process.

The actual Bot runs the process, or automation as it is called. The Bot starts the automation when it is triggered. A trigger can be a human starting it, which is called an “attended” Bot, since it is attended by a human, or other events like a schedule, an e-mail, or a file being deposited. Each Bot is able to run many use cases or automations, maximizing their output and efficiency. For instance, if an automation runs for 10 minutes every day, the actual Bot has 23 hours and 50 minutes left to run other automations. Bots are not 100 percent efficient, so a Bot running 24 hours a day may not be realistic. But Bots do have about 8,760 hours per year available to work, in comparison to 2,000 hours per year for a human. The Bot that runs the service is managed by another software tool. This tool schedules, monitors and manages the Bot. Bots can be scheduled to run at any time, including nights and weekends, meaning you could come into work on Monday morning and find the work you needed complete and in your inbox, or posted online for others to use.

Bot Scheduling

As mentioned above, Bots come in two forms: attended and unattended. An attended Bot is one that is “attended” by the user, meaning the user starts the Bot and the Bot utilizes the user’s credentials, permissions and accounts. In most cases, it will consume the user’s computer processing time and not allow the user to multi-task on another problem. An attended Bot can be used when a human decision needs to be made about starting the Bot, or which Bot to start.

In most cases, our goal is to use unattended Bots. An unattended Bot is one that is not “attended” by the user and utilizes its own credentials, permissions and accounts. It would also have its own computer, which in most cases would be a server. An unattended Bot can be available 24 hours a day, 365 days a year, though it likely will not be used non-stop. The Bot management software will schedule the Bot at the best time for the assigned process. Some will run every night or once a week, while some may run when a kickoff task like an email is received. And yes, Bots can receive and send emails.

Credentialing and Access Management

One of the most significant challenges for setting up an unattended Bot is creating the appropriate credentials and system access. As the user of an attended Bot uses a PKI (public key infrastructure) credential on his/her Common Access Card (CAC), the Bot needs a similar PKI credential to log onto CAC/PKI enabled systems. The simplest way to accomplish this is for a Non-Person Entity (NPE) persona to be created for the Bot. This NPE would be very similar to a user’s persona and have an e-mail account, but for an unattended Bot, the E-credentials need to be hosted on the server/computer and used for account access. Once the PKI credentials are in place and the systems that the Bot needs to access have accounts for the Bots, you can make this work. The Bot needs the same access as the user and follows the same Role Based Access Control controls. The Bot’s access needs a System Authorization Access Request (SAAR) but the automatic SAAR processes may not work for a Bot, so using the older DD-2875 might be required.

There are two ways that Bot credentials can be utilized. The first is using an alternative token card, similar to a CAC, but for the Bot. This token, while inserted into a CAC reader, can be used to hold the Bot’s credentials to access a CAC-enabled system or website. The downside of this solution is that a human must be available to enter a personal identification number (PIN) and maintain possession of the token. The second solution is to store the soft credentials on the Bot server and utilize a Hardware Security Module to handle the access normally provided by a PIN. This allows Bot access all day, every day to CAC-enabled systems.

Process Selection

When deciding which process to automate through RPA, we rely on workforce input. We use various management tools to get that input and identify potential processes. Once we have the nominees, we work through an analysis phase to determine whether to proceed with automation. During our analysis, we determine two things: First, can this process be automated, even partly? Many times during the analysis of the process, we find that the process needs to be improved before a Bot can automate it. A process must be stable and repeatable for automation to work. The second thing we learn is whether the process is worth automating. Does it have the appropriate return on investment or other benefits? Generally, for simple processes, we are looking at a minimum of 500 hours in yearly savings, significant dollar savings or assistance in an audit finding.

Once a process passes our criteria, we move into the next three phases; design, develop and test. Currently, we break our phases into 2-week sprints, and many of the processes only take one sprint to develop. More complex processes may take multiple 2-week sprints to develop. During the design phase a technical design document is created that describes the design and includes a flow chart outlining the process. During development, we use an agile development cycle with frequent check-ins and collaboration to ensure our customer’s needs are met. After development, we use a final testing phase to identify any additional corrections before deployment. Since there may be corrections identified in the testing phase, we expect to roll corrections back into the process and retest.

Finally, we finish with a 2-week production-ready sprint, which allows the product to move to the production environment. As an unattended Bot moves to the production environment, the management software must be set for specific rules: When does the Bot run, how often does it run, what are the expectations for reports, etc. Additionally, we monitor the Bot for a week or two to ensure that automations are getting the results we expect. This has a secondary effort of increasing the customer’s confidence in the Bot.

RPA Operations Center

So once the Bots are running, it’s all done, right? Well, not so fast.

The Bot management tool not only schedules but also manages and monitors the Bots so that we will know if the Bot failed to run and why. Perhaps the e-mail exchange was down or the system that the Bot was to interface with was not working. The Bot management tool will send a report to the right people to let them know that the Bot didn’t run, and then the team can figure out if we need to fix the Bot or run it again when the appropriate systems are back up.
What if the auditors want to track what the Bot is doing? Well, the Bot logs all actions and stores them in great detail, including time stamps. Additionally, a report can be provided to outline all the important metrics about the Bot.

The RPA Operations Center (ROC) is the clearinghouse for all this data and where the Bot managers work. In the ROC, the Bot managers watch the Bots for performance issues and manage them for efficiency.

While the Department of Defense and the commercial industry find that Bots can be a powerful tool, they are not the solution for every process and they require work to set up and manage. So ask yourself: What do we do that a Bot can do? If you’re not sure, ask your Bot team.

In the meantime, remember: A Bot’s work is never done, and Bots are here to help!

Read the full issue of

Defense Acquisition magazine



LOCKWOOD is the Robotic Process Automation program manager for the Defense Logistics Agency at Hill Air Force Base in Utah.

The author can be contacted at [email protected].

Subscribe LinkPrint Button