Robotic Process Automation: From Concept To Working Tool

In recent years, we've seen many organizations initiate proofs of concept for their AI initiatives. The drive is there to address business challenges using advanced technology, often with robotic process automation (RPA) in scope—but success, for many, is elusive. Why?

As a first observation, many organizations fail to recognize that the gulf between a proof of concept and an enterprise-wide solution is huge. They often underestimate the skills needed to scale up effectively.

The reason for this may be a misconception that RPA can be simply onboarded without the need for IT or any deep changes to the business, a belief that results when RPA vendors, eager to sell their product, say their technology can be easily installed and used by any businessperson. Many organizations have consequentially fallen into the same trap as ten years ago, when cloud services were purchased by businesses without IT involvement, creating what IT organizations now call "shadow IT". While many try to avoid this by setting up centers of expertise to better match technologies to business needs, these centers tend to end up existing in vacuums, failing to incorporate enterprise architecture standards on the one side, with IT guidelines and processes on the other.

Common mistakes at a more granular level

Three mistakes tend to recur when it comes to RPA platforms:

Design: Most proofs of concepts take a "freestyle" approach, ignoring the constraints of the production environment. Thus, while running on a single machine, the proof of concept doesn't incorporate advanced features that will eventually be required in production (queuing, security access, etc.) As a consequence, a "copy/paste" approach when moving to the production phase introduces problems that were not foreseen or tested for. Scaling: The technical architecture supporting the proof of concept might not be rightly sized for production. A typical error is just to assume that an increased workload of x% will require, on a linear scale, x% more infrastructurebut it's not as simple as that. There are non-computing aspects to remember too, such as not to underestimate input-output needs. Monitoring: The new environments of RPA platforms can also create nightmares for operations teams. Part of the problem is a misconception that RPA is error-proof, leading to a less rigorous check for problems (in the form of special cases or exceptions) in the proof of concept. These issues then become very apparent in...