RPA process that you should adapt for all your RPA projects
On , by
The process of a RPA project is extensive as it involves extensive research and asking questions to know exactly where you are headed. Once you know the end result you are working towards, you will need a process in place. You can refer to how to ask the right questions during an RPA project requirement gathering, here.
An RPA project process can be split into two phases. Each phase has four to five sub phases that needs to be carried out. Our experience with RPA has helped us put together the process and the protocols to be followed.
Below you can find a detailed overview of each phase and the sub phases.
Initial Process Analysis(IPA)#initial-process-analysis-ipa
Before diving into the whole automation process, the current workflow should be captured from the client or the vendor. This process helps to set the ground for automation and gives an ideal perspective on the process.
In IPA, the higher-level description of the manual process is captured, and all the unique situations are considered without any failure.
The RPA analyst does this analysis with the client’s SME (Subject Matter Experts).
After the IPA, the process has to be refined. Every single process should be documented, and the same automation solution is analyzed along with it. The efforts and the time taken for the conversion of the manual process to automation are measured, approximately.
In the refining process, the documentation helps in capturing the missing links and information.
In IPA, the scope of the applications used is documented and validated, whether it can be automated or not. For example, Excel can be automated, but few exceptional applications without any middleware will have problems in automating, and this is validated during the IPA.
This refining process has to be done by the RPA analyst along with the client’s SME information.
After the well-documented process, the walkthrough model helps in avoiding incorrect flow, identifying any missing scopes and importantly helps in prioritizing the start and end of the project’s scope.
The documentation supports a few flowcharts, user-workflow diagrams, and screenshots.
This entire process walkthrough document is required from the client-side and it is easier to implement with more detail. This workflow aids the RPA developer to understand every minute details in the application’s scope and gather the knowledge in relating the things for automation
This walkthrough has to be done by the client’s SME and will be recorded by the RPA developer.
The automation mostly interacts with the client’s software and server. To start the automation, the RPA developer needs access to a sandbox server and a sandbox machine on the client’s end to understand and implement according to the workflow discussed above.
The system requirements for each phase has to be documented. There are three phases: development phase, testing phase, and production phase. And the requirements for each of these phases are documented to estimate and structure the solution workflow.
Considering the development phase, the need for an agent is on only one machine. The testing phase requires 3-10 agents to test, and the count sometimes varies depending on the use case.
This communication happens between the RPA analyst and the Client.
Automation Based Requirements:#automation-based-requirements
By this phase, the workflow must be with the data gathered from the customer. Now, requirements for the automated system is captured by communicating with the client.
These requirements cover the standard alerts, logs and the emails that will be sent in respect to automation.
The automation needs data like - When the should the log be deleted? Where should the log be stored? How can it be sent? Who can access?. All these questions are answered and documented for the automation system requirement.
This is communicated between the RPA developer and the client’s SME.
Automated system development:#automated-system-development
The manual process which is broken into steps during the “Refining Process” is built into an automated solution and is documented in a Solution Design Document (SDD). SDD helps the client to understand what solution is provided by the development done at the particular X period.
The client goes through SDD to verify whether all solution complies with the walkthrough recorded and approves the solution. This helps in maintaining the development in line with the solution expected and avoiding ad hoc changes.
RPA developer communicates with the Client using the SDD.
Similar to the process workflow done by Client’s SME, the solution workflow is carried out by the RPA developer to the client, and this walkthrough gives clarity over the development stages.
Solution review is essential to ensure whether the development is in line with the solution promised.
Client’s SME can review this solution and approve them.
In the testing phase, different scenarios are documented during the system requirement phase and are tested.
With 1-agent or mocking 2, failed agents and the automation is executed, and the process is summarized. Finally, using the test summary, a few changes/improvements will be done and will be moved to the production phase
Test summary will be recorded by the RPA developer and sent to the client.
After a few regular testings, the bot is pushed live, and access to the production server instead of the sandbox server will be provided.