8 simple tips for supporting your digital workforce

It was 1am.

I was awake and confused. My heart thumped out of my chest.

My phone screeched and buzzed. Unknown number. Ugh... another P1.

It was late 2010 and I knew that it wasn't going to be one of the easier fixes. When I'd started supporting the solution it had been pretty scary being alone at night responsible for fixing something critical and not having anyone to call upon for help. The buck stopped with me.

Right then though, I felt confident I'd get in running again. If it had been a year earlier, I wouldn't have been.What was the difference in that 12 months?

A wiki.

When I was bleary-eyed, my brain was foggy and I was alone in the eerie early hours, having an easy to find step-by-step guide for fixing an issue was exactly what I needed.

And that's why it's my first tip...

Have an Operational Handbook

Whether it's a wiki (my personal favourite) or just a Word document - have each process the digital workers are running well documented so anyone could support it.

Covering basics like...

• Process name and description including criticality
• Business Process Owner contact details
• Links to key related documents like PDD, SDD and BCP
• Steps for rerunning it or resolving any common issues

Write down your Support Policy

Having a support policy, even if it's a simple Word doc at first, will provide a basis for how your digital workers will be managed moving forward.

Capture basics like who to call for infrastructure issues or for certain target applications, and make sure it's easy to find for the team. It's really annoying for both managers and team members when they have to keep asking who to call in each situation.

As well as key contacts, the policy should record your SLAs - both for your environment and target apps, but also for you delivering support to your internal customers. How quick will you commit to responding to and resolving incidents?

Sure these details will evolve over time and be added to for different scenarios, but if you don't have a policy in the first place you are hampering yourself.

Insist on Business Continuity Plans

The BCP is an element that's generally considered in relation to the platform and not always at a process level. Having a clear plan on what to do if a particular process can't operate requires some effort to put in place. There can be a lot of reasons why this isn't a priority.

Over time though, the need becomes more pressing. People move roles, knowledge is lost. The risk becomes greater.

Unlike the rest of these tips though, this one is the responsibility of the process owner rather than the RPA team. Having said that... it does fall to the RPA team to make it clear a BCP is required. The pain will fall on you otherwise if the worst happens. Think like Batfink and make yourself as bulletproof as possible.

Automate what you can

Look at automating how you manage your digital workers. From automating password resets to raising support tickets when a target application goes down. Automate daily checks. Whatever your team are doing to support the digital workers, take a look at what actions could be automated. I've seen some great examples of control room activity being performed by digital workers themselves, including triage of certain exceptions. Automate the automations. How very sci-fi.

Build for support

Consider exception handling during the build so you can minimise the amount of support needed once a process is live. For example, build in the handling of business exceptions to go to the business user with a clear instruction on what's gone wrong and what might be needed.

It's not uncommon to see business exceptions going via the Process Controller to the business owner, sometimes that's necessary, but a lot of the time it's not. Consider this at the design phase.

Build reusable objects you can add to each process to handle common exceptions and to report on key information - this can help with problem management (see point 7). There is no need to keep reinventing the wheel when you can plug pre-built components in to each process.

It's good to talk

Have a good relationship with the business and application owners. Be plugged into change advisory boards so you know when application changes might be coming. Speak to the business regularly and ask how it's going for them.

I once found out a team were bypassing the automated process as it was only automating part of a process and they were having to go into the system anyway to finish a task so they just did the whole thing. No one in the business had told us this was happening and we only asked the question when we saw the process wasn't running many cases. Many things would have avoided this situation of course, but a regular call would have certainly helped.

Problem Management

I spent several years managing a problem management service and it wasn't easy. Incidents always came first so my team were always battling with higher priority live issues when trying to get resources to look at ongoing problems. Even though resolving these would reduce the number of live fires, it was hard to see past the immediate flames.

From an RPA perspective it's good to regularly review exceptions for each process to see what improvement work can be done, even if those exceptions are well-handled. From a support perspective, if you hear the statement "Process X as fallen over again, just restart it"... it's a sign it's a frequent recurrence and needs to be looked at.

Implement Acceptance into Service

You can automate a decent chunk of this, but at it's very basic, having a checklist of stuff that needs to be in place before a process goes live will save avoidable headaches.

Is there a handbook and BCP in place? What happens if this new target app goes down? Has a change record been raised for the release? You get the gist. It's a useful gate for Process Controllers to own as ultimately they are the ones on the front line dealing with the outcome if these things aren't in place.

And some final thoughts...

Supporting and managing the digital workforce is often the last element teams consider when setting up an RPA service. In many of the deployments I’ve seen, support has been an afterthought and to quote Tom Jones... "it's not unusual".

The initial priority when getting started is to find some processes to automate and then start building them. Running the digital workers isn't at the forefront of everyone's mind. But as time passes, it's importance becomes more and more. So set up for success early and avoid that technical debt.

To find out more about some of these key themes, check out the Service Model of the ROM.