RPA is a journey not just a project
Let's look at the path this journey takes
Architecture of success
RPA will reach its full potential at the end of a consistent process. We like to think of it as a journey, one in which a virtual workforce is deployed by the organization to help achieve its long range corporate goals.
Considering RPA a short term project (perhaps to cut process costs or increase accuracy) will hold back some of the benefits a fully grown, healthy implementation usually provides.
Build a competitive edge
Undertaking an RPA journey enables companies to: plan and execute the technology on an enterprise-wide basis, integrate siloed operations, applications and data, build internal capabilities to adapt and scale, and more importantly, create business value and competitive advantages.
Preparing for the RPA journey
Good preparation is always key to a successful journey. This one makes no exception, as organizations need to plan ahead, synchronizing and harmonizing their resources for a seamless process.
The most critical elements of this preparation are:
Steps in a typical RPA journey
Every journey is unique, reflecting strategic priorities; timelines are also unique, varying in accordance with process complexities, resourcing and compliance requirements. However, UiPath identified these four stages as part of every RPA evolution process.
1
POC
This first step does more than proving how RPA can boost success. It also allows the organization to decide the role it should play in the implementation model, what automation partnerships it needs and which partners to choose.
2
Pilot
At this point, an automated process is run into production for the first time, according to the organization’s implementation model. This means the organization and RPA partners apply defined requirements, a detailed solution design, test scripts and cutover/handover plans to the selected process.
Pilot performance is monitored in accordance with its exit criteria. In addition, all internal and external stakeholders are surveyed for feedback. This input is the basis for documenting lessons learned and revising methodology and frameworks before advancing to ramp up.
3
Ramp Up
The primary focuses of this step are:
• optimizing management of the newly deployed virtual workforce,
• establishing best practices,
• qualify additional processes for automation,
• continuing growing the internal automation team and its expertise.
During the ramp up phase, champions should accelerate activities designed to identify further RPA opportunities within the organization and showcase process automation successes to a broader business audience.
4
Institutionalize
The point of this final step is to establish best practices for robotic processes automation as a baseline activity within the organization. Specific examples include governance board to manage the process automation pipeline demand; disaster recovery and business continuity plans; continuous improvement based on lean Six Sigma with the automation team.
Beyond including these practices into the organization’s culture, this moment should also include a continual evangelizing of RPA benefits based on existing implementations, while promoting RPA as a key performance objective across all business lines.
Missteps to avoid
along the way
Reading through these basic steps of the automation journey, does it not seem remarkable that many RPA implementations either suffer disappointing outcomes or end as outright failures? It did to us when we first began working with customers who came to us after experiencing either one or the other. Over time we identified several common implementation mistakes to avoid.
Immature vendor selection
RPA tools from several vendors have evolved quickly from simple workstation robots to complex enterprise software. But in many organizations, perception of RPA technology has failed to keep pace, as their selected vendors cannot meet IT and business architectural requirements.
IT Architecture: there is a general awareness IT departments require new technologies to conform with architectural criteria. For example: open & extensible technology, stable and well documented; common skill sets and solid security compliance. RPA tools should be no exception.
Business Process Architecture (BPA): the selected RPA tool must be able to automate across all key business process. Whether in virtual environments, utilizing OCR, requiring cognitive intelligence, etc. BPA defines and documents those key processes, along with relationships and interdependencies, making it a perfect framework for compiling a vendor selection criteria.
Proof of Concept (PoC) confusion
The point of a POC is not to confirm if RPA technology does what it claims to do. The primary POC purpose is to test business case assumptions, validate the best implementation model and assess RPA integration and technology partners.Yet confirming RPA capabilities remains the POC goal for many organizations. This mistake typically leads to a circumstance in which POC proves little, is not actionable and often slows down RPA momentum. It proves little because a volume of solid business cases already confirms the technology works. It is not actionable because a POC validating RPA does not provide insights into how it might work within that specific organization. Momentum is hurt because there is not an obvious next step. The POC should be designed to lay the foundation for the much more definitive Pilot step in the journey, and provide the answers and validations needed for approval to move onward to the Pilot.
Immature process selection
Loosely governed RPA pipelines often wind up with very complicated process automation candidates. Perhaps it is a case of overconfidence, as one might say “RPA can do anything!” Or it might be a subjective decision to pick a highlycomplex pain point over a simpler savings opportunity. It is a mistake in either case to abandon disciplined priorities. For at least the first full year of a RPA journey, selected processes should be restricted to low or medium complexity that demonstrate an aggregated potential to save at least one FTE.
Misguided automation target
Some organizations get so caught up with the idea of a fully automated end-to-end process they overlook the reality of diminishing returns. Others become so focused on automating complex process steps, that the thought of eliminatingthose steps with redesign never actually occurs. It is important to remember the low cost, low invasive nature of RPA. Unlike other automation technologies, it can generate a high ROI with only a partial automation of process steps. Attempting to extend automation too far into a process can lower ROI by significantly increasing implementation costs. Likewise, process optimization is often a smarter route to savings than configuring a robot for complicated rules.
UiPath Product Suite
Created for the needs of global
enterprises and BPOs.
UiPath Studio
Customer success begins with our Studio Designer: the perfectly intuitive environment where anybody can model automation visually, without scripting, without code. A powerful recorder literally builds automation by watching you work and a rich library of template activities will get you moving at an exceptional speed and ease.
Read More...
UiPath Orchestrator
The heart of our products suite. A highly scalable server platform, Orchestrator deploys and manages your entire workforce, handling all the critical enterprise duties: release management, centralized logging, reporting, auditing and monitoring, remote control, scheduling, workload management and asset management.
Read More...
UiPath Robot
Our star performer. The UIPath Robot can take the role of an automated assistant running efficiently by your side, under supervision or it can quietly and autonomously process all the high-volume work that does not require constant human intervention.
Read More...