Decisions, decisions… automate with RPA or upgrade your core system?
I have been reading quite a bit about this specific topic, and talking to a few businesses lately about the dilemma they face between automating more of their processes with RPA or upgrading their core systems to incorporate the process changes.
Obviously, there are many different aspects to consider like: life expectancy of the core system, complexity of the processes, volume of processing throughput, anticipated business or process change, development resource available, and many others. However, while I imagined there would a clear swing for an imagined nirvana state and historical approach of wanting everything in their core systems, this was not always the case! So, I thought I would share some of the more innovative thinking businesses have come up with.
Some businesses may still want to automate more of their processes within their core systems at some stage in the future, but they have chosen to automate many processes with RPA first. Why?
- The return on investment and business benefits will be realised far sooner than they would expect to have the solution delivered as part of their core system enhancements. Comments like “two months as opposed to 12 months” or “in months not years” were mentioned.
- The cost of establishing an RPA process to manage the bulk of transactions was cheaper than the software development required on their core systems to manage the full array of transaction variations.
- They get the advantage of learning and documenting the ‘real’ processing requirements as part of the RPA automation before needing to develop this logic into their core system – some have stated automating a process with RPA before incorporating this into their core system has in fact saved them money, and the organisation was able to refine the process as part of the RPA implementation first.
- It gives them more flexibility around their core systems upgrade schedule, as more important or urgent requirements may come along – some stating there is a high likelihood of this in their agile delivery model: “our processes are being continually pushed to the end of the queue; that’s why they’re still manual processes!” [and not already built into our core systems].
Some other organisations have taken a very methodical approach, being selective about what goes into their core systems and which processes will be developed with RPA. Why?
- Processes which are prone to being changed often are usually more suitable to be developed with RPA, allowing for faster implementation of changes, and reduced maintenance costs.
- Where a process manages a huge variety of transactions, these often require a ridiculously large amount of processing logic to be coded and tested as part of a core system upgrade, rather than an RPA solution managing the bulk of transactions and the referring the edge cases and business exceptions to be managed by humans.