Acronotics executes automation programs in the agile mode. The schedule is broken up into a series of sprints, with each sprint running over 8-10 weeks covering business analysis, bot design, bot development, unit testing and UAT.
Each sprint can have one or more automation pods. Each pod has 3 automation engineers working as a team on a set of logically related processes. One pod can automate 3-5 processes in one sprint. So if a sprint has 2 pods, it can automate 6-10 processes.
In addition to the pod(s), the sprint team typically includes the following resources (shared across the pods)
This approach ensures that:
Each sprint comprises of the following sequence of activities:
Analysis & Design
The Business Analysis Phase is usually the first two weeks of each sprint, during which the Acronotics team gets a detailed understanding of the as-is processes from the client’s process SMEs. The following is a list of activities involved (for each process):
|Document as-is process in Process InVision
|Process Walkthrough (meeting)
|Process SME + Acronotics
|Prepare draft Process Description Document (PDD)
|Process Review and Clarification (meeting)
|Process SME + Acronotics
|Develop Solution Design Document (SDD)
|Prepare Test Cases
|Review Test Cases
A Process Walkthrough is a discussion between the process SME(s) and the Acronotics BA(a) to understand the as-is process in detail. Process walkthroughs need to be scheduled with the relevant SME(s) for each process.
The SME(s) should document the step by step flow of the process in a process mapping tool (such as Process InVision) and share it with the Acronotics team before the walkthrough.
During the walkthrough session:
After the walkthrough session Acronotics prepares the Process Description Document (PDD) and shares it with the SME(s) for their review to ensure all the steps, variations, exceptions etc. are fully captured. Once the SME(s) sign off on the PDD document, and Acronotics starts developing the automation solution (SDD) for the process based on the same.
Bot design process involves Solution Architects (SAs) analyzing the as-is process flow and designing the to-be (automated) process and high-level bot structure in an SDD document. This phase will also involve some discussion with SME(s) if there are parts of the process that have feasibility challenges like usage of dynamically generated one-time-passwords (OTPs).
Below are some of the best practices for bot design:
Automation Pods (teams of 3 automation engineers) work with SAs and BAs to understand the process & bot design and develop bots as per the requirements. Deliverables that are created as part of the bot development are:
Below are some of the coding best practices for development of bots:
User Acceptance Testing (UAT)
Business Analysts (BAs) co-ordinate with Process SMEs to conduct UAT sessions of the bots. The process involves running the bot as a demo to the SMEs for them to visually see the bot in action and then review the results of the bot execution in form of processed transactions and process logs generated as part of the execution.
Below are some of the best practices for UAT:
Bot deployment is one of the topics that is often ignored till the last minute and should be considered early in the process to avoid implementation delays and improve reliability of bots as they move to production. It is important make sure that bots follow well defined bot promotion process as they move from Dev to UAT and to Production environments. We work with our clients to finalize the bot deployment process in early stages of project.
Before we move the bots into production, the following points need to be taken into account:
As part of the production cut over, the following points need to be taken care of: