Scroll to top

The Process

RPA will reach its full potential at the end of a consistent process. We like to think of it as a process, a journey, one in which a virtual workforce is deployed by the organisation to help achieve its long range corporate goals. It is usually a collective work. Your task is to find out all aspects of a process through open discussions and surveys, describe them and making them available to all stakeholders involved. Knowing the obstacles and exceptions up front, and having examples, is probably the key part of implementing process automation.
You should start small – begin by focusing on a single process that you want to resolve and take actionable steps. However, 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.
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.

During meetings, conferences and training sessions, we’re often asked: What can we do to make business processes more efficient? What tools do we need? How disruptive and difficult to implement within company culture automation process is?  But most importantly: Where do we begin?

It is an absence of answers, experience and motivation that form the greatest obstacles to take step towards automation. Good preparation is always key to a successful project completion. This one makes no exception, as organisations need to plan ahead, synchronising and preparing their resources for a seamless process. The most critical elements are:

Stakeholders team up

RPA journeys are based on strong relationships and coordination, usually the main stakeholders involved are Business and IT. The Business side leads the way, focusing on primary goals: creating business value, lowering operational costs or/and increasing revenue and sharpening competitive advantages. The IT side engages these goals by acting upon future-proof scalability and extensibility, ease of deployment and meeting architecture and compliance standards.

Define the purpose

The journey must be in-sync with the organisation’s strategic direction. Otherwise, the project can easily get sidetracked into lower priority activities, unlikely to take full advantage of the automation.knowing your purpose, needs and benefits sought can greatly help you to define the scope and direction of the project. It is almost impossible to find a company that would not benefit from automating workflows and company processes. The common misconception about RPA is that it needs to be very lengthy and costly process, while the reality is very much different. Often, automating even a small fraction of business operations can result in substantial time savings.

People in charge

In order to reach its full potential, the journey must be lead by a senior level champion for effective adoption and budgeting advocacy. Personal dedication and motivation to change things are the most important factors.
Leadership is crucial and the strongest possible implementation manager must be selected. This key figure will focus on key aspects, by selecting the most advantageous process for proof-of-concept: well-documented, reasonably high volume, repetitive and rules-based.

Determine priorities

The moment you start designing plan for the automation is the time to come up with priority areas. You will need to decide which processes you want to focus on first – which ones can save you most resources when fully or partly automated. The following two rules are very helpful when prioritising. Focus on short, frequently recurring and simple processes. This will allow you to achieve early results with minimum resources and interruption, inspiring you to continue implementing automation in other areas. Do not force your way into areas with the highest resistance to change and/or lowest benefits from automation. The change needs to come within – these employees will join later themselves after seeing their colleagues being more happy with their workload.

Cultural acceptance

The C-level champion and implementation must have a joint plan of action to win organisational hearts and minds over to an authentic and proactive adoption of the RPA journey. There is a big difference between buying from a company who uses robots, and working alongside one. The fear that workers will be replaced by robots is a sensitive subject, and should be handled tactfully. For automation to be embraced internally, company leaders need to help workers understand how it benefits them. Businesses should also review their goals from an ethical standpoint before deciding to automate. The more common it becomes, the more automation will be accepted by consumers and employees alike.

The first rule of any technology used in a business is that automation applied to an efficient operation will magnify the efficiency. The second is that automation applied to an inefficient operation will magnify the inefficiency.
Bill Gates

Every organisation is unique and each RPA project needs reflecting these unique strategic priorities and timelines. There are many various factors influencing process complexities, resourcing and compliance requirements. However, Untrite identified these four general stages as part of every RPA evolution process.

When reading through these basic steps of the automation journey above, it may seem strange that many RPA implementations either suffer results misaligned with objectives or end as outright failures. However, many customers fall in traps of implementation mistakes as a result of little or no good preparation. Below we list just some of those mistakes to consider when preparing for RPA journey.

Unfit vendor selection

RPA tools have quickly evolved from simple GUI robots to complex enterprise software. But in many organisations, perception of RPA technology has failed to keep pace, as their selected vendors cannot meet IT and business architectural requirements. 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. The selected RPA tool must be able to automate across all key business process which organisation requires.

Over-complex proof of concept

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 organisations. This mistake typically leads to a circumstance in which POC proves little, is not actionable and often slows down RPA momentum. It is not actionable because a POC validating RPA does not provide insights into how it might work within that specific organisation. 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.

Misguided priorities

Some organisations 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, while what’s actually needed is eliminating those steps with redesign. 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 optimisation is often a smarter route to savings than configuring a robot for complicated rules.