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 infrastructure—but 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 production—and come as a shock.

Better to be safe than sorry

It takes a task force to ensure that the RPA deployment will be fully predictable. Such a task force should be put in place while the proof of concept is still in progress, combining representatives from the center of excellence, the business side, and IT. Its objectives should be:

  • to learn the entire proof of concept, and then design an RPA platform using the current IT operations context, leveraging enterprise IT architecture and the existing processes framework for IT service operation (e.g. incident management, configuration management)
  • to identify which supporting environments (Dev, UAT, Prod) are needed as part of the software development lifecycle—in other words, how RPA will fall within DevOps framework—and to align testing scenarios
  • to assess how well the target operating model (e.g. its processes and toolsets) can monitor and manage RPA components; it's crucial to get the right tool for monitoring bots and to define both what will be made automatic and which procedures are needed to restart the bots (when required)—log analyses of bot performance should be implemented as well for any business-critical applications
  • to identify relevant skillsets and new roles required across the RPA "value chain"


We have seen a lot of procrastination in RPA implementation: action is delayed, critical questions go unaddressed, and enterprise-wide deployment doesn't happen. A lack of confidence usually comes from a lack of knowledge, meaning that step one is understanding the technology and what its implementation really entails—from the business side and IT alike.

When figuring out how to develop the capability and infrastructure necessary to support scaled RPA deployment, organizations must also remember that RPA will, by default, require more agility. This is because implementing new processes will happen much faster with the new system.

Without the right structure and governance, an RPA project will fail. Ultimately, organizations need an appetite for long-term investment if they hope to deploy their disruptive technologies meaningfully on a broad scale.

The content of this article is intended to provide a general guide to the subject matter. Specialist advice should be sought about your specific circumstances.