Tech mahindra
Tech mahindra

SPA before RPA or RPA before SPA? Making Sense from All the Buzz

Posted by: Kiran Wadhwani On April 07, 2017 12:17 PM

RPA practitioners have - in various forums globally and across industries - discussed, debated and analyzed multiple aspects of RPA. Most of these conversations are centered on what RPA is, what it can and cannot do, its business impact on entities in the ITES & BPO value chains, the different kinds of Governance, Implementation, CoE & Support models required to successfully answer business objectives, so on and so forth.

These debates have also seen several doubting thomases scoffing at the way RPA has been “played up & unnecessarily hyped” by the industry at large. These folks aren’t ready yet to lend support to or believe the disruptive nature and the benefits of this Automation category. Having said that, it is also true that some of their critique does have merit, so rather than rudely brushing them aside as prophets of doom, one should closely analyse the fail-points/concerns raised by them and find out ways to correct them.

However, in all of this continuous chatter, another conversation piece on RPA has slowly emerged over the last year or so and has now become a very strong discussion point in all forums. That piece is Smart Process Automation (SPA) or Intelligent Process Automation (IPA).

So, what is SPA or IPA? Is it a subset of RPA or is it altogether a different category of Automation like RPA? If the latter is true, how are the dots between these two subjects connected? What are the constituting elements of SPA/IPA? Let us take a quick look at the genesis of SPA and try to answer these questions as correctly as we can.

It all started with some industry experts, researchers, data scientists and RPA evangelists looking for ways to “better” RPA. Most of us already know the limitations of RPA. That RPA yields the best returns on only those processes that are system-intensive based on rules that can be hard-coded using conditional operators such as If/Else & have near zero decision points that require human experience/judgement. The other way to measure RPA yield is to find out the extent of data extraction from artefacts that come in multiple forms, formats & templates v/s the extent of data extraction from artefacts that come in one form, format & template.

For e.g. let us look at a typical Invoice process that has one principle artefact type called: The Invoice. It can come in either as an image (OCR engine required for data extraction) or as a digital doc with selectable text (OCR engine not required for data extraction). It can also have multiple formats; Word file, Paper, Fax, PDF file, XML, XLS or for that matter data housed in applications such as ERPs, Mainframe, CRMs, et al. Lastly, it is also likely to have multiple templates (each vendor will have its own invoice template), which in totality makes the entire input data feed highly unstructured.

Therefore, although a typical Invoice process that is built on rules and is system-intensive (in some cases it may not be) may look like a high-yield RPA candidate, in reality it is not! Just the number of combinations an artefact type like Invoice can generate makes it unfriendly for RPA

No. of Combinations for an Invoice artefact = No. of forms X No. of Formats X No. Templates

E.g. 2 X 3 X 80 = 480 artefact combinations.

One may argue that although the cost-benefit may not be good enough for all 480 combinations, but an 80-20 Pareto logic (effectively 96 combinations) can be applied to find out high-volume combinations that can yield good returns. This argument may theoretically be strong but it falls flat in the face of cumbersome and tedious support, administration & change management exercise required for these 96 workflows! All that and more, it signals the end of RPA for this process before it even begins!

So, what are the realistic options to make this highly repetitive and manual invoicing process RPA-friendly? Either reengineer it to accommodate humans and bots working in tandem with seamless handshakes between them, or introduce “Smart” in RPA (Machine Learning algorithms supported by NLP & OCR technologies) to manage data extraction from the unstructured feed.

Hence, for RPA-friendly processes (ones that consume relatively less unstructured data feed – about 20% to 30%), OCR+NLP+ML combined with RPA can deliver incremental benefits beyond what RPA has already delivered. For such processes, SPA is nothing but a natural extension to RPA and it can be applied only after RPA has done its job. Meaning; a strong RPA layer is necessary have for “Smart” to be implemented.

Whereas, SPA can be treated as a separate Automation category for processes that consume about 60% to 80% unstructured data feed. In addition, unlike RPA-friendly processes, a strong RPA layer is good to have and not necessarily a must have.

(*) symbol is mandatory field
* Email Address:


(*) symbol is mandatory field

Post a Comment

* First Name:
* Email Address:
Image Code
* Enter Image Code

For further information please write to

For further information please write to