Mainframe RPA

As far as employees are concerned, nobody really likes doing boring and repetitive tasks. Why not let the mainframe do them. As far as businesses are concerned, anything that enhances the service levels they can offer their customers has got to be good. What ticks both those boxes? The answer is robotic process automation (RPA).

So long as there aren’t any changes needed to existing applications and no new hardware, then anything that increases productivity, reduces errors, and improves the service available to customers – whether they are internal or external – has got to be a good thing.

RPA isn’t new. Gartner were very excited about it in 2018, suggesting that it was the fastest growing software sub-segment that it tracked. However, it seems to be gaining more popularity in the mainframe arena over the past year.

Let’s be clear, when we’re talking about robotic process automation, we’re not talking about some 1950s vision of the future where robots will be doing the work of humans. It’s just software that will be automating repetitive tasks.

Essentially, computer software – often referred to as a software bot – captures and interprets application data and automatically performs the mundane work that can involve manipulating data, executing transactions, triggering responses, and communicating with other systems.

Most often, the automation software actually connects with the existing software by a process called screen scraping from a 3270 or 5250 terminal emulator. It takes information from a screen that would have been available for a human to look at. This, as you can imagine, is not the best way of going about things, and can result in numerous calls to the mainframe in order to get the data that it needs. A more modern approach is to use RESTful APIs into the existing programs to communicate backwards and forwards. That way, you know the information going into the RPA software is accurate, and the results going back to the application are error free. And, it can mean far fewer calls to the mainframe.

The other advantages of using APIs rather than screen scraping are that the application will still work even if the layout of the screen ever changes. The speed that the RPA software can work is measurably faster than with screen scraping. And fewer mainframe cycles are used in the process.

Other hidden benefits of using RPA include the fact that if employees are happier because they aren’t doing routine tasks, they can be focused on higher value-added activities. And that will make going to work more interesting for them and will also have a positive impact on the productivity of a company and, potentially, on customer satisfaction.

The downside for staff that aren’t able to pick up on these other tasks is that automation leads to fewer staff being required. For an organization, the benefit is that they will save money on their payroll costs. Obviously, training those staff is a better option, or HR can find them jobs elsewhere in the company.

For people project managing an RPA project, who are used to cost and time overruns for projects, and who often face user disappointment with the finished project, the good news is that RPA projects are non-invasive, which means that they can be completed without causing disruption to the existing ways of working.

One of the benefits often associated with RPA is the increased use of analytics that becomes possible. Firstly, the quality of the data is much improved making the analysis more reliable. More data can now be included in the analysis. And the analysis that is carried out can be more sophisticated than before.

Another, perhaps hidden benefit, is with compliance. The automation means that there is less human contact with sensitive data, which, therefore, reduces the opportunity for data theft, fraud, or other compliance issues. RPA also allows for audit trails to be kept, which can be used to prove to auditors that the system is compliant with whichever regulations apply to that industry.

Apart from loss of employees through redundancy mentioned above, there are some other downsides to RPA that often don’t get a mention. There’s the potential for there to be scaling issues, in terms of adding more and more bots in a piecemeal fashion. This then becomes harder and more costly to maintain and manage. There’s also the issue of ensuring this extra layer of software is properly documented – particularly in the event of a problem (eg a business continuity event) occurring.

Many organizations simply automate their current processes because it makes sense to simply do that, and the automation will probably work. However, it makes better sense to review all the current processes to see whether they can be made more efficient before the automation takes place. This takes away any likelihood of inefficiencies in the original process being amplified by the automation process. As well as speeding up inefficient processes, the automation may also add to the cost of the process by the frequency of these inefficiencies. Lastly, piecemeal automation can make things more expensive than looking at the big picture in the first place and automating as much as possible in the first iteration of the RPA introduction.

RPA seems to offer lots of benefits to a mainframe-using organization, but there are also potholes on the way that need to be avoided to get the most from the opportunities that the automation process offers.