Loading...

4. Attempting process perfection

Every process has variations and exceptions. If-that-then-this. The problem is, many RPA developments try and account for as much variation and exceptions as possible – usually because that’s what the business wants. But if 80% of your process takes 20% of the development time, why would you spend a huge amount of development time for such a small incremental return?

Scope your process better than you think you’ll need to. Watch dozens or even hundreds being performed by people. Speak to expert front-line staff (avoid managers telling you what happens – they don’t know enough detail).

Agree what the bot will do and how it will handle variations. Write that down. Scope creep is a killer.

Focus on the Minimum Viable Product (MVP) that will produce the most benefit for the least effort. You can always build more complexity later (if that’s the right thing to do).

6. Lack of integration with IT development & support

If you’ve had a ‘business-led’ implementation of RPA (which is cool) then there’s a good chance that the RPA development team is not plugged into IT the way it needs to be. This is OK when you’ve only got 1 or 2 processes but it becomes a real problem, real quick when you have some scale.

You need to be on distribution lists. You know, the ones that say when planned outages or core systems will occur? Or the ones that tell you a planned upgrade to a core system is being released? 

Who’s going to support the developments? Who’s the first line of support? IT help desk or RPA devs? How will your coordinate effort with the Network guys if that turns out to be the issue?

You need to be working in coordination with IT – which can be a real problem if IT don’t view RPA as a serious solution (see #2).

7. Constrained investment

If you’re going to seriously deploy RPA, you need to invest in it. You’ll need to hire or train (or both) some people in whatever RPA platform you choose.

Don’t rely on consulting firms as your single source of RPA development. Consulting firms are great to help get you started, put the right things in place, set you up for success and help you provide flexible resource when your demand outstrips your internal supply. But you’ve got to have some internal capability. You’ll need this for when something goes wrong or a change is made and you need to respond quickly to alter the RPA process to get it up and running again.

Make smart choices about your costs. Doing it externally will always be more expensive than internally. But you might need 10 developers for 12 months and then 4 developers thereafter. Using a firm to help with short term demand is really, really helpful.

8. Lack of awareness

About 12 years ago, I was improving processes in an organization. I found a staff member whose job it was to report on SLA performance. To do this, they were manually counting the start date and end dates on an excel spreadsheet to work out how many days had elapsed. For 1,000’s of records, every day.

When I asked if they knew a formula could calculate this for them, they replied: “Yes, but using a formula doesn’t take into account weekends, and our SLA report is based on working days only”.

They didn’t know about the NETWORKDAYS formula in excel which can discount weekends and public holidays. 

My point is that the end-users of processes, the ones who know the processes better than anyone else are likely to have a very low awareness of RPA (or probably none at all). Same goes for first-line managers. Spend some time teaching people about RPA. Run Lunch and Learn sessions and roadshows. Get people interested and excited about what RPA can (and equally importantly what is can’t) do.

9. The unnecessarily high cost of development

Every RPA development must have a dedicated development environment, a UAT environment and a production environment. All systems it intends to access must have a development version to do the build. Test data will need to be sourced and applied to the Development and UAT environments. 

Except it doesn’t. There may be some examples when the above is appropriate – but they are not the majority and should be scoped and cost from the outset so you know what you’re getting into. 

Here’s the thing about RPA – it’s using the User Interface. This has already been exhaustively and thoroughly tested before going live. The Bot isn’t going to use the system any differently from a person. Yes, it needs to be tested – but you can often do developments and testing on the live system. There are reasons why sometimes you can’t or shouldn’t, but they are usually the exception, not the rule.

You’re NOT developing applications. Don’t take the standard App Development framework and apply it to RPA. 

If you’re taking a full App Dev approach then your costs per RPA deployment will be at last 2X the cost and can be as high as 6X the cost.

10. Governance from hell

Does something like this sound familiar?

That idea will need to go to the Centre of Excellence Governance Forum. Once you’ve spec’d it – it will need to go to the Architectural Review Board. You’ll then need special dispensation from the Digital First Steering Group. From there we go to the Product Board. Data Protection Board will need to approve and authorize the use of data. It will then need a pass from the Resilience Committee and then you’ll need the solitary tear from a Himalayan yak before Finance sign it off.

Or you can just stare at a wall for three months and be more productive.

RPA is a great technology that can help reduce shadow IT and end-user solutions (like Macros and Access databases) that many organisations use to plug process efficiency gaps. It is a really valuable tool in the toolbox of process improvement.

But it’s important to learn from the mistakes of others to make the most of your investment.

Cameron Turner – Lean Consulting