Limitations of RPA

Limitations of RPA

It is these benefits that are generating the boom in the interest of the RPA and a good measure of exaggeration. However, each technology has its limitations, and RPA is best seen as an additional level of cost reduction and a fundamental technology instead of an operational panacea.

Limitations of RPA include :

First, RPA can not read any non-electronic data with unstructured entries. An example would be incoming correspondence, such as customers' printed letters. When a client sends a letter to their energy company or bank, it is usually an unstructured document. A company would then receive, scan and reassign this letter to the correct department for processing. In this case, RPA will only work with a collection of other implemented technologies (such as OCR) necessary to make it digital and structured. This can become a costly obstacle before RPA can be applied, and companies can consider other solutions such as direct processing, digital capture, process optimization or other intelligent automation technologies.


Second, companies should be aware of the various contributions from multiple sources. For example, in an acquisition function, supplier invoices can be received in different formats, with fields located in different areas. For a 'Bot' to read an invoice, all supplier invoices must be received in the same format with the same fields. Although robots can be trained by exception to read different fields, they can not read multiple different formats, unless all are digital and are configured separately. In practical terms, there will always be a volume and cost threshold below which RPA is not an economic solution, and companies must first focus on high volume / high cost processes to obtain the maximum benefit.

Third, RPA is not a cognitive computing solution. He can not learn from experience and, therefore, has a "lifespan". As processes evolve, for example, through the introduction and use of other technologies, they can become redundant and require changes. Therefore, it is prudent for a company to examine the process before building a "Bot". In general, in our clients we see that the useful life of a Bot is three to five years after the implementation. Applied to a process that is inefficient and / or is in the process of leaving, that useful life can be reduced to only one year. The business case can not then be accumulated.


Finally, the application of RPA to an inefficient and broken process will not solve it. RPA is not a Business Process Management solution and does not offer a complete view of processes from approaches such as Lean Six Sigma. The same goes for the obsolete infrastructure: RPA will only hide the underlying problems. This can counteract any long-term sustainable savings by adding complexity that needs to be addressed in the future. Companies must first focus on addressing the root causes of their inefficiencies in the process or technology and then apply RPA to maximize the benefits.

Comments

Post a Comment