The Parallels Between RPA and Fax Automation
There are times when the cheap and nasty solution is so economically efficient that it can preclude doing it properly later on.
Background – The Fax
Just under a decade ago, I was working with a local authority client and their NHS hospital partner. The interpretation of the law at that time was that email was considered a non-secure channel. Fax was at the time the chosen channel since it was considered to be secure.
So documents were sent from the hospital, via the fax machine to the fax machine in the social care offices. Continuing Health Care panels met to decide on whether the NHS or the local authority paid for the care, based on whether the primary need was a health need or a social care need. That’s simplifying the logic behind the process and the decision but it’s enough detail for this article.
To be able to make that decision on tens or hundreds of thousands of pounds per year per person, that panel needed to review the data about that individual carefully. So this meant that 40-150 pages per person would be faxed from the hospital to the social care office.
The process for this was relatively convoluted:
- the hospital professional (therapist, nurse, discharge planner, etc) collates the documents
- they ring the social care office and tell them they’re about to send the documents
- they feed the documents into the fax machine
- they’re sending more than the fax machine can fit into its auto-document feeder, so they have to standby to top it up
- at the other end, the fax machine starts printing
- the social worker picks up the paper before it falls onto the floor
- the fax machine runs out of paper (several hundred pages per panel and it’s likely that you’ll have to refill the paper)
- the social worker obtains blank paper, loads the fax machine with the new paper
- the social worker collates all the faxes
- the hospital professional rings the social worker to confirm that they have the documents.
The First Proposal – Email
Naturally, the partners want to make this more efficient so the design conversation usually reverts to proposal of email. But, as mentioned earlier, that’s not considered secure. Or at least the email solutions available at that time were not secure.
But there is a strange alternative.
The Implemented Solution – Fax Gateway
We used fax gateways at either end. It turns an email into a fax to be communicated on the phone line, to then be converted back to an email at the other end. The revised process was a lot more efficient:
- the hospital professional (therapist, nurse, discharge planner, etc) collates the images ready to be sent (e.g. prints to file or scans in the remaining few that they don’t have electronically)
- they send an email containing the fax header and the documents to their fax gateway
- at the other end, the fax gateway converts the received fax into an email for the social worker.
- the social worker reads the email and downloads the attachments ready for the panel
It’s a solution that shouldn’t have existed. It relied on old technology but until the law caught up with the technology (or the technology caught up with what it had to do to be secure, e.g. nhs.net accounts, etc), then it was the cheap, workable solution. But it was messy and I shudder every time I think of it as a solution. However it made it better for the clients, making the process simpler for them as end-users and freeing up time to do more important work.
Front-End RPA
That’s what the current state of RPA feels like to me. Not the whole of RPA, but the element that’s involved in the user front-end of systems. It’s like the fax gateway. So instead of the better solution of orchestrations between the various IT systems involved, we’ll automate the front-ends.
The Parallels
Now I’m wondering if we’ll see the same situation with RPA as we did from implementing the fax gateways. We found ourselves with a cheap and nasty solution which then made the business cases for full integration prohibitive.
Why would you spend hundreds of thousands of pounds on a better solution when the cheap one works adequately?
So if that angle of RPA solves the automation from a front-end, replacing the mundane tasks performed by employees, why would we look to orchestrate the back-end?
Will initial RPA implementations deter us from better integration of products? And, more importantly, is that necessarily a bad thing? After all, my NHS and LA client were still able perform better with the cheap solution than they were able to without it, and they also avoided a costly integrated solution. In the end, it was a temporary measure until secure email became a practical solution for them and their partners. I’d expect to see parallel initiatives nowadays with RPA, with clients improving their efficiency through the introduction of RPA, but avoiding more costly integration. Especially, as a temporary measure that will likely have a longer-than-intended lifespan.
Recent Comments