Phases and roles in an RPA project

So, your organisation has decided to implement an RPA robot. After careful consideration it has been decided to automate a process that contains a high level of predictive, repetitive activity with structured data that traditionally has been handled by an employee or a group of employees.

All the prerequisites have been fulfilled as to the formal parts: The project has been sponsored by the COO, CTO or CEO. A steering group has been appointed. The business side have been appointed as the future owners of the robot.

The project can now kick off. We use an agile project methodology as we deal with development of software. Implementing an RPA robot can be divided into four parts. Each having its own distinctive start and end.

Depending on the organisational culture and its bureaucracy, experience tells us that the first two stages may take up to 70% of the time of the project. This is the pre work, dealing with the business side, before starting to design the robot, testing it and implementing it.

The four phases of an RPA project and the activities within

In the assess phase we investigate the process (or processes) that could be automated. Questions that we want answers to are:

• Is the process repeated several times a day?
• With a high degree of predicable outcome?
• Does it deal with structured data?
• Is the process cross organisational or is it contained within a department?

We also evaluate key criteria such as KPIs and critical success factors for the RPA implementation. These need to be agreed and set before the implementation so we can measure the effect the robot will have.

The stage ends with an assessment report that outlines the RPA project in more detail and the feasibility of it.

The second phase, the approval stage, is labour intensive as it is during this stage an agreement about the pilot process to be automated is reached. When a decision about which process to automate first is reached, it is followed by a thorough investigation and documentation of the process.

After documenting the process in detail, we would also design the future process – the one with the robot. It will look different as some of the human interaction and activities are now performed by the robot.

Placing the current process chart next to the new process chart will visualise how the introduction of the robot will alter the process.

This stage ends with a Business case being presented to the steering committee and the sponsor of the project. It contains the expected cost and the Return on Investment (ROI).

At the design stage we would look at the process and start looking at which software vendor best fulfils the criteria outlined in the business case. Different software have different advantages which might and these might be better suited to the organisations needs and future demands. When that choice has been made we would acquire the license from the preferred vendor.

During this phase we would design the exact process and have it signed off by the business. It is then a question of designing the robot.

This stage ends with testing the robot. The robot should first be aimed for quick wins – activities in processes that do not add value but take time and effort. With agile iterations the robot will be programmed to increase the level of automation.

This is an iterative process and several iterations are performed as the robot is fine tuned. When the robot mimics the users behaviour to a very high degree and when all exceptions have been programmed it can be ready for release.

Implementing the robot is the exciting part. The robot is now released into the working environment, mimicking an employee’s behaviour. When installed, it is up to the business side to monitor the robot and handle any exceptions. If there are changes in the process, the robot may have to be reprogrammed and it is the business side’s responsibility to either do it themselves (if they have the programming knowledge) or bring it to the IT departments attention.

After having been in operation it is time to measure how productive it is and what the business impact is. Is the process faster? Do we save time? Does it increase revenue? Do we save resources?

After evaluating this first project, it might be time to look at your next automation project.

The roles in a project

To successfully implement an RPA project it is recommend to specify the roles at the start of the project. The roles can be filled by external (consultants or interims) or internal resources.

The three roles mentioned below make up the core team, the bare minimum. There are other roles that will help the project succeed. People with skills such as change management, IT architecture and Operation and maintenance will play crucial roles during the project but these roles should be defined when scoping the project. Often there are other IT projects ongoing and co-ordinating with these is crucial.

Project Manager

Books have been written about project management. Read those for a more extended role description.

In short, the project manager is responsible for the whole project, from assigning resources to getting the KPIs and measurements correct and getting the budget approved. These have to be done before the project starts.

During the project, the project manager is also responsible for developing the business case and present this to the steering committee. The business case is the formal document that outlines how profitable the RPA implementation is likely to be in pounds and pence (or dollars and cents) and its expected pay-back time.

Business Analyst

The business analyst’s has three different roles in an RPA project.

During the Assign phase, the Business analyst works with the project manager in identifying the processes, evaluating the key criteria for RPA (which might be different from the CTO’s point of view and the business point of view). Having experience of business process mapping is of essence.

During the Approve phase, the role is centred on documenting the current process (gathering the tacit knowledge from the business users, their tasks and activities) and designing the new process (with the robot). It requires knowledge of drawing and documenting processes but also business acumen and a willingness to observe and ask questions.

During the Design phase, the Business analyst together with the RPA developer work with the business in detailing the process. This is done during a number of workshops. During this phase we tend to ask very specific questions about where, how and why one uses a system, what exceptions there might be in handling a specific task and which processes interact with the process we are automating.

RPA developer

The RPA developer will use input from the Business analyst and the process charts to develop the robot. He (or she) is the expert at programming (and might test) the robot.

As there are many vendors of RPA software, an organisation will have to be careful to choose the right RPA software. And, as RPA developers are thin on the ground, their cost can be considerable. Make sure the RPA developer has been certified by the software firm.

As the robot has to mimic user behaviour in a process, performing tasks perfectly, it is important for the RPA developer to have a good understanding of the business and the process itself. He (or she) will have to spend time with the Business analyst during the workshops to gain an understanding of the tacit knowledge that surrounds the process.

It is also important that the RPA developer understands .NET technology and that he (she) is well versed in high-level programming languages like VisualBasic. Experience in working with web browsers (MS IE or Edge, Chrome and Firefox) is of importance as is knowledge of Citrix for remote desktop and virtualisation in general.