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:
Business & IT partner-up
RPA journeys are based on strong relationships and coordination between Business and IT. The Business side leads the way, focusingon primary goals: creating business value, lower operational costs
and competitive advantages. The IT side engages these goals by acting upon future-proof extensibility, high deployment velocity and meeting enterprise architecture and compliance standards.
The journey must be in-sync with the organization’s strategic direction, always. Otherwise, the project can easily get sidetracked into lower priorityactivities, unlikely to take full advantage of the automation. In order to reach its full potential, the journey must be lead by a C-level champion for effective adoption and budgeting advocacy.
Select for success
Leadership is crucial, as the strongest possible implementation manager must be selected. This key figure will focus on key aspects, by selecting themost advantageous process for proof-of-concept: well-documented, reasonably high volume, repetitive and rules-based.
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.
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.
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.
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.
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.
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.
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.
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.