If you need RPA, you have already lost!

RPA a great solution for a shitty problem.

Legacy code, Legacy systems … I don’t think they deserve such a grand term. They are systems that cause pain and frustration, but not to the right people. If it did they would have been patched, fixed, removed or improved. But again, IT peoples pain is not a high priority.

But a solution is needed. But not prioritized enough to fix it the right way. The fix needs to come now not later, because doing it the right way would take too long. Never mind the time and or money it would save down the line. Businesses have become impatient and this feeds into the prioritization process. Time is money and a better solution that will save time and money down the line will not come up on the quarterly report. And is it really worth doing if you can’t show it to your bosses boss in a powerpoint with lots of graphs showing how much time/money you have saved this quarter.

I am starting to sound a bit bitter. I’ll try and tone it down.

The argument of ‘cant we just do it right from the beginning’ is getting really close to being uttered here. The only solution is the perfect solution and nothing else will do. That is not what I am trying to say. But holding on to legacy systems that have no modern way of communication and creating robots that will manually punch in a series of inputs to get the data into a system with no api what so ever should not be the preferred solution either. But I am getting ahead of myself here

The Problem

You have a system. Often an old system that manages some data. This has been used since the early 2000’s, 90’s or even late 80’s when the company was small and the data was miniscule. Penelope in accounting punched in some data every other week and life was good. It has now been 20 years. The company has grown quite a lot since then and the data with it. Penelope now has 4 assistants that mostly just punch in data at this point. Something has to be done. Does this system have any form of api? No it was made in a time where we measured internet speeds in kb/s and listened to the modem scream bite’s at us. There is no api, there is nothing but the GUI and Penelope in accounting. And this is often not just 1 system but many. And it might not even be a program, it might be an excel spreadsheet with so many macros that it will scare the most seasoned of junior programmers.

• Insight: None
• Logging: Never heard of it
• Pace: The snail’s

What do?

Well going from our two viewpoints earlier the utopian mind would maybe think that we could replace the old system with something new and performant. Something with lots of insight, lots of logging, something reliable. Something we could programmatically call so that the data goes straight where it has to go. Something with an api that we could leverage like all the other technologies. Also this is not a unique problem maybe we could use something that has been used in similar situations at similar companies, maybe even something open source?

Then there is the doomer that will just suggest that we hire more interns to punch in the numbers moore quickly…

Now here we have come to the crux of the issue. A fateful decision has to be made. How will we move forwards. Leadership wants to minimize costs, or at the very least get to say that whatever the solution is they were the one that came up with it. IT just wants something that works and that requires little effort to maintain but since we have differing opinions and hiring monkeys on a banana salary as “interns” was apparently not a good idea 😞 We will then hear the fretful words “lets just meet somewhere in the middle”. And we meet the bell curve of doom.

Taking two wildly different approaches and trying to “meet in the middle” will make no-one happy, the resulting solution will not be as good for it and IT will have spent more time and effort making the chosen solution work than it actually would have taken to implement the “utopian” ideas that were proposed from the beginning.

What I am trying to say is that there are a lot of people that say things like “that is not realistic” and “we cant just throw this away” (referring to the ancient system that is still being used) that are not hearing the others in the conversation out.

Yes implementing a new data flow can be complicated. Yes there are a lot of options for solutions that could replace the old one. Yes we would have to find out if there are any unknown dependencies for the legacy system. But sometimes you have to do hard things in the start to do less effort later. This calls for another extremely complicated diagram.

But what does “meeting in the middle” actually look like in practice? It often means a patchwork solution that neither fully replaces the old system nor optimally integrates with modern technology. It’s a compromise that satisfies the budget constraints and the immediate needs but fails to address the underlying issues.

The Middle Ground Solution

You could automate the process with RPA, keeping the legacy system just as rusted and rotten as it is whilst automating most of the workload. This looks like it saves lots of time and effort. It looks like this mostly from the perspective of managers that don’t actually do the work of developing these solutions. As one who has taken part in setting up RPA systems to automate manual work, it is really not that quick and effective as the sales reps would lead you to believe. It takes deep knowledge of the process’s that will be automated and the systems that we interact with as well as the data that will be processed. In the end you will have a solution that will still rely on the outdated legacy systems GUI that is a often a bottleneck for modern data flows but also prone to changes that could break the automation. Its cheap in the short term. Looks great on a quarterly report. But a headache in the longrun.

The Ideal Long-Term Solution

When you have to do all of the work of charting and discovery of the legacy system either way, why not do it properly. You have done half the hard work that is needed. And most of the time the discovery is more than half the battle. Requiring you to dive into ancient tomes of long forgotten documentation that is literally a binder of loose A4 papers. But once that is done, modern solutions keep getting simpler and simpler to implement and develope. That excel document that some manager used to fill out for onboarding new employees for the Hr system that then gets punched in manually by Penelope and her assistants, is now a tiny webapp that is just a good looking form with some nice company appropriate styling, that gathers all the needed data via a nice and simple form. It will even let you upload a nice picture of the new employee so that it will show up in teams on their first day. This webapp will then send the info gathered to the backend that is just some framework-backend like sveltekit. It will then format the data into all of the api calls that are needed and send those bad boys out. Depending on the recipients of these calls the changes would be near instant and the cost of this internal only webapp accessed by maybe 100 people a month would be around 5 - 10$ a month using something like Azure-Static-Webapps. This can all be logged and monitored in 10 different ways many of witch are free or very cost effective.

“But what if our HR system does not support updating employee data via an api?“. Well here comes the hard part. GET A NEW HR SYSTEM!

This is some of the fallout solutions like this will have. Cascading changes will have to be made some of them more painful than the others. But if you do them for the right reasons and think them through they will leave you in a better place in the end. And I swear to all that is unholy in these trying times if your HR system has no solution for interacting with your employee data other than SFTP file transfers of spreadsheets… get a new rusting HR system! 😡

Conclusion

Look. I get it. RPA can fix some things. And if a system works perfectly fine other than not being able to receive data from the source you need, then setting up an RPA middle man and an automation process can be a good solution. But you have to think about it, and I mean REALLY think about it. If there are any other problems with the system or some kinky complications with implementing RPA, it is often simpler, cheaper and more IT person friendly to just use some of the amazing tools that have been developed in the last 5 years or even 10 years. There are smart, simple and cost effective solutions out there. you just have to be willing to go with something that might not seem easier in the start.

But trust me. IT people are lazy. They will do anything to have to do less work later even if the wall looks a bit taller in the beginning.