GovLoop

First to Automation, NASA Takes RPA Agencywide

NASA astronauts Nicole Mann and Josh Cassada watch as a United Launch Alliance Atlas V rocket with Boeing’s CST-100 Starliner spacecraft onboard is rolled to the launch pad at Space Launch Complex 41 ahead of the Orbital Flight Test mission, Wednesday, Dec. 18, 2019 at Cape Canaveral Air Force Station in Florida. The Orbital Flight Test with be Starliner’s maiden mission to the International Space Station for NASA's Commercial Crew Program. The mission, currently targeted for a 6:26 a.m. EST launch on Dec. 20, will serve as an end-to-end test of the system's capabilities. Photo Credit: (NASA/Joel Kowsky)

The National Aeronautics and Space Administration (NASA) was the first federal agency to officially implement robotic process automatoin (RPA) after the NASA Shared Services Center (NSSC) introduced the idea at an agency kickstarter competition in 2017. After receiving some initial seed money, NSSC became NASA’s testing ground – and the larger federal government’s testing ground for RPA. The south Mississippi office has since been so successful with eight bots across 40 processes that RPA will be rolled out agencywide in April 2020.

With the launchpad of its Washington Bot, NSSC’s project has served as a model for RPA efforts at the General Services Administration (GSA) and other federal agencies. GovLoop talked to Pamela Wolfe, Chief of NSCC’s Enterprise Services Division and the leader of its RPA program, about taking the first step for government bots, the challenges that came with being first and what’s next.

This interview has been edited lightly for length and clarity.

GovLoop: NSSC was first in the federal government to bring in RPA. How did that idea come about?

Wolfe: Our portfolio manager was looking at innovation opportunities, and NASA had an innovation kickstart contest, where people submitted ideas for innovation. Then, some were selected and given some seed money to do a pilot or proof of concept. Our portfolio manager submitted an idea about RPA, and we were one of the finalists that were given some seed money to do a proof of concept for RPA. That’s really how we got started.

It was really plowing ground that had not been plowed before in the federal government – a lot of work to determine how you would put digital workers into your workforce and get them access to systems, a lot of scrutiny on the IT security aspects and the credentialing of these digital workers. As a matter of fact, we went live at the NSSC, providing these services, in January of ’18, and we are in the process of rolling this out agencywide.

Oh, wow.

Yeah, and scheduled for that to go live in April of next year, in April of 2020. So, we’ve been working very heavily on governance and there’s a lot of lessons learned and things that we’ve shared with other government agencies as they started the journey. We’ve identified similar issues that we felt needed to be addressed at a federal level.

Just going back to being the first agency to ever do this too, what challenges came with really stepping foot on untrodden ground?

Well, certainly there were a lot of IT security concerns around the software and the vulnerabilities that may be present when you’re doing this, and our IT security team had a real concern about giving the bots access to systems.

Frankly, there are two camps on that. From our financial segment auditor’s perspective, they really like the unattended bot, because they can go into the system of record, they can identify when a bot is doing a transaction, and they know exactly where to go to get the audit and the control information and the documentation associated with those transactions. Conversely, our IT security team really wanted to use attended bots, because of their concerns with allowing bots to have access to their systems. There was reluctance with thinking that these bots could go in and make system changes, which they absolutely cannot do.

You have 40 automations in place. So, are there 40 bots in place then, or do some bots tackle multiple automations?

Across the industry, we’re learning that some people use “a process” and “a bot” interchangeably, and they’re really not. So, we have 40 processes in production, but we have eight bots in production. We have multiple processes running on a single bot, as long as the duties for those particular automations do not conflict with each other.

Once you’re automating a process that was busy work for employees, do they pretty quickly get on board?

Oh, they absolutely get on board quickly. And as soon as you automate one mundane task, they’re ready for you to automate the next one.

I wonder if you actually started this trend in government. I’ve always been interested in the different names that are given to RPA bots. And of course, for the first one, you all went with Washington. What went into that decision?

Well, you know, it’s funny that you mention that, because we spent a lot of time on how do you name the bot. In our pilot, we had to identify one bot and several things were thrown out. So again, our portfolio manager at the time said, “We’re just going to start with the presidents, okay.” And so, we started out with Washington Bot, and then we had Adams Bot. But once we had those two in place, we had this huge discussion about how there is no diversity in the presidents.

It went round and round and round, and finally, we all decided we would go with the NASA missions. So, our first two were named for presidents, but after that, it goes in sequence based on when NASA missions were.

This article is an excerpt from GovLoop’s recent report, “Getting Started: Answering Your Questions About Robotic Process Automation.” Download the full report here.

Photo credit: NASA Flickr

Exit mobile version