Once you’ve selected your pilot project for your first RPA bot, these are the steps we’ll then take to help you get the most out of your experience working with us::
1. Gathering Process Details
In order to program the RPA bot, we need to produce a list of manual process steps which includes the software being used, and the data to be extracted, or inputted into the application.
For simple or straight forward processes, a Line-Manager or a SME (Subject Matter Expert) can simply add these steps in a word processer or spreadsheet.
Sometimes though, either the process is complex and has never been documented, or the exact detail of each step needs to be recorded. In these circumstances, there are three main techniques which can help capture this information:
Sticky Note Review
As the name implies, here we capture the process steps on sticky notes, either physically or using an online ‘sticky note’ application such as https://note.ly which is useful if the team is working remotely.
In a group setting, this technique is not only useful for describing the manual process steps, but also allows for discussion amongst the group, perhaps amending the process and even improving the efficiency of the process before automation.
Company employees might think they know the process, however it is not until they start to document it that they realise that extra sub-processes are happening that they didn’t know about, or the sequence they thought was followed is, in fact different.
Sometimes it is useful to record the process and its steps into swim lanes, each lane representing an application or department for instance.
The diagram below shows a Sticky Note Review, with the green sticky notes denoting the swim-lane titles, while the yellow notes are the process steps.
Sticky Note Review Example using note.ly
Process Mapping/Flowcharts
Process Mapping using a Flowchart can be used to formulise the sticky note review above, or if the process is already known, can be used straightway to describe the steps in the process.
There are various tools available to do this, including those within the Microsoft Office Suite. We’ve found that Online tools such as Lucidchart ( https://www.lucidchart.com/pages/ ) or Draw.io (https://drawio-app.com/exploring-bpmn-shape-libraries-in-draw-io ) have additional functionality, making the documentation process easier.
Take a look at our case studies. Each has examples of flowcharts for their RPA automation.
Process Video Recordings
Another powerful way of recording a manual process is making Video/Screen recordings of process activities. The video can then be replayed, and started/stopped to document the various steps in the process.
This is particularly useful where there might be complex business rules within a process, particularly if audio voiceover is added with an explanation of the step.
Processes conducted by remote workers can be captured efficiently with this technique, and makes automation without physically seeing the process in operation possible.
An RPA provider, such as Autane, will take these video/screen recordings of the process and translate them into flowchart steps for the client.
There are various video/screen recording tools available with free versions including Screencast-o-matic (https://screencast-o-matic.com) and Loom (https://www.loom.com/screen-recorder), which also store recordings in the cloud, facilitating the sharing of the video with the Business Analyst.
Other options include PowerPoint which includes a Screen Recorder as standard (https://support.microsoft.com/en-us/office/record-your-screen-in-powerpoint-0b4c3f65-534c-4cf1-9c59-402b6e9d79d0 ).
Key Stroke Document
At a more detailed level, each process can be recorded in a Key Stoke Document. This document lists each process activity by the key strokes, and which buttons are pressed on the keyboard, to complete the process step, together with their respective screen shots.
Sometimes, this is useful for documenting complex activities which might involve the use of hotkeys on the keyboard for instance.
2. Process Design Document (PDD)
The Process Design Document (PDD) is crucial for documenting the process and importantly communicating the bot requirements to the RPA developer.
It is a confidential specification for the RPA automation and describes everything the developer needs to know for the process to be automated.
This includes the software applications being used, and details of the exceptions that need to be programmed into the robot to handle various process scenarios.
Initially drafts of the PDD might go back and forth between the Business Analyst, and Project Sponser/Subject Matter Expert, while various details are confirmed and amended.
Obviously the more thorough and accurate the document is before development starts, the easier the development process, and more likelihood the bot will run smoothly when it is launched into a production/live environment.
The typical headings for a PDD include:
- Process Analysis
- Process Overview
- A description of the current manual process and its purpose
- Development Credentials
- Any login names for accessing the systems, but excluding passwords
- Systems involved
- A table of Software Applications describing what there are used for, and any access requirements/roles needed
- Process Flow Map
- A flow chart and/or swim-lane chart of the process which will be automated.
- Detailed Steps
- A series of numbered process steps with headings and a description of each step, and cropped screenshots of each step. Reference should be made to any of the relevant exceptions listed below.
- Test and Test Data
- What and where is the test data? Obviously it is preferable that live-data is not used during development, and dummy data is made available for tests.
- Assumptions
- List of assumptions used as the basis for the automation. For instance, the format of input data.
- Outstanding questions
- The PDD might be waiting for information. For instance, confirmation of one of the process steps which does not stop development work from starting. This can be documented here and updated along the way.
- Process Overview
- Possible Exceptions
- Logic Exceptions
- These are ‘If-Then’ type rules within the process. If this scenario happens, then do this.
- System Exceptions
- Dealing with potential issues with the systems the RPA bot is accessing. For instance, what if a software application does not open – what should the RPA Robot do then?
- Logic Exceptions
- Appendix
- Test Sheet/Schedule
- Detailing the various steps and scenarios to be formally tested and then marked as PASS (or FAIL if there are bugs to be ironed out)
- This should include all the required steps and exceptions above so they can be ‘ticked off’.
- Test Sheet/Schedule
3. RPA Coding and the Development Process
With regards to the development process from a client point of view, there is little to do, assuming a comprehensive PDD has been written.
Of course, in reality, the developer might still have some areas that need clarifying or clearing up, and they might contact the client periodically during the development process.
Development normally ends with the developer conducting and completing the test schedule. At Autane, the test schedule is sent to the client to confirm that the robot has been programmed and will function in accordance with the specifications laid out in the PDD.
4. Going Live and into ‘Production’
Once the robot has passed its tests and has been developed, it is ready to be eased into production. This is normally split into three short phases as follows:
User Training/Instruction
To handover, some instruction for the end user of the bot might be necessary, and is normally delivered by the Business Analyst. The depth of training/Instruction depends on level of automation and covers the following:
- Start-up
- How to start the automation and whether it is triggered automatically on a schedule or started manually.
- Process Inputs/Outputs
- What and where to place process inputs, for instance invoices to be processed by the bot
- Where output objects such as processed documents are placed, and whether any reports are outputted. For instance, in our Garage Case Study, if the bot could not read the supplier invoice, the details were placed in a Google Sheet for human review.
- Bot failures
- If the process environment changes unexpectedly, the RPA Bot can fail. For instance, if the input fields are changed by the developers on a Software Application used by the automation, and there is no exception written to handle it, then the bot will fail. The user needs to be given instruction to identify the failure and what to do next. Do they restart the bot or contact the developer immediately?
- At Autane and our Robots-As-A-Service (RAAS), we constantly monitor the performance of the bot. This ‘early warning system’ generally allows us to identify any problem and fix the bot without the client knowing about it.
User Acceptance Testing (UAT)
Before putting the bot into regular production, some form of User Acceptance Testing (UAT) will be conducted, where the process owner will test the bot on a small batch of live data, verifying that the output is as expected.
This includes handling and recovering from any exceptions. Sometimes the Business Analyst will be present during UAT, either physically or via Zoom.
If the bot fails at this stage, it’s normally because not all the process scenarios where not captured at the PDD stage, and unexpected exceptions occurred. For instance, during UAT of the Property Management Company RPA Case Study, unexpected popups appeared in the software application for certain scenarios which the Bot was not programmed to deal with and it subsequently failed.
A Bot ‘Fail’ in UAT means the process is passed back to developer for further work. A full ‘Pass’ indicates process has been handed over successfully and the bot is ready for a production launch.
Babysitting new Bots and ‘Hypercare’
Even after successful UAT, we generally find that a certain amount of ‘Hypercare’ is needed by the development team. What this means is that a developer will watch-over or ‘Babysit’ the first few production runs of the bot, just to double-check nothing has been missed at this stage. Again, if the PDD wasn’t thorough enough, unexpected exceptions might occur which might need further developer work to resolve.