Bot Development

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)

• A Team lead (TL) with end-to-end responsibility for all the pods
• A Solution Architect (SA) who helps the automation engineers to develop the optimal automation solution for each process
• One or more Business Analysts (BAs) who help in creating the Process Description Documents (PDDs) & Solution Design Documents (SDDs)
• Optionally, one or more Quality Assurance (QA) lead(s) who help the pod teams in testing the bots
• Optionally, production support engineers who get added to the team after the completion of the first sprint for on-going support of the bots as they go into production

This approach ensures that:

• Sets of 3-5 bots are going into production every 8 weeks or so. The program can be scaled up to deliver more bots in each sprint by simply adding more pods.
• Related processes can be grouped logically into a pod so that they can be analysed, designed and built together.
• This minimizes the amount of time that process SMEs have to spend with the automation team for the business analysis (related processes can be covered in one workshop by the same SMEs).
• It also ensures that bots are smartly designed with a layered/ componentized architecture (as common elements across related processes can be built as reusable components).

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):

Task	Owner
Document as-is process in Process InVision	Process SME
Process Walkthrough (meeting)	Process SME + Acronotics
Prepare draft Process Description Document (PDD)	Acronotics
Process Review and Clarification (meeting)	Process SME + Acronotics
Signoff PDD	Process SME
Develop Solution Design Document (SDD)	Acronotics
Prepare Test Cases	Acronotics
Review Test Cases	Process SME

Process Walkthrough

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:

• The SME(s) give the Acronotics team a live demo of how the process is carried out as of today.
• The SME(s) walk through all the different scenarios/ variations to the “happy path”.
• The SME(s) walk through the various errors/ exceptions that are known to occur during the process and how they are to be handled.
• The SME(s) identify all the applications/ technologies used in the process.

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

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:

• Utilize the standard structure of one master bot with several sub-bots to ensure modularization of bots
• Use Single Responsibility Principle i.e. each logically separate functionality of the process or bot should be encapsulated in one sub-bot
• Ensure usage of standard re-usable components from Acronotics common repository like for error-handling, login to a common application like Service-Now etc.
• Ensure the bots take care of not just the happy path or automated part of process but also the exception scenarios i.e. inform and enable the process SMEs to handle exception scenarios in case those need to be addressed manually
• Ensure the bots are designed to handle the volume of transactions in the given SLA window i.e. if the volume of transactions is high the bot might need to be logically broken up for load balancing and parallel execution from multiple runners
• Collaborate with process SMEs to design the to-be process if changes are expected in up-stream or down-stream parts of the business process/ underlying applications

Bot Development

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:

• Technical design document (TDD): Detailed document about the bot code including the pseudo code
• Peer-review sign-off: Every bot is peer reviewed by another automation engineer to ensure that coding guidelines are being followed
• QA sign-off: Internal testing by QA team ensures that bot meets functional and technical requirements

Below are some of the coding best practices for development of bots:

• Use configuration file for all the environment level settings to ensure no changes are required in bot code for migration of bot from dev to UAT & from UAT to prod
  • No hard coding of paths, file names, URLs, etc.
• Ensure usage of comments to explain the code as much as possible
• Two types of logs need to be created for different audiences: 
  • Process log: For the process SMEs to know the functional progress of the bot and exceptions that might need to be handled.
  • Technical log: For the support team to troubleshoot in case of failure.
• Ensure standard naming convention for variables, folder structure, config files, input and output files
• Ensure error handling at two levels 1) enclose the whole code in an error handling block and 2) every critical part of the bot in its individual error handling block
• Use credential vault or encrypted store for credentials or other information that needs to be secure

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:

• Ensure the test of exception scenarios in addition to the happy path scenarios.
• Conduct the UAT execution of the bot from control room instead of developer’s workstation/VDI.
• Plan ahead to make sure SMEs have time and bandwidth to create the test data for all the test scenarios.
• Ensure access to UAT systems is gained well before the bots are ready to go into UAT to avoid delays.
• Document any changes/ defects discovered during the UAT session and if possible, communicate the timeline for the fix to ensure availability of test data and SMEs for next UAT session.

Bot Deployment

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:

• Make sure that bots have been properly tested in UAT environment and have received a UAT sign off
• The underlying application environments that the bots access in UAT need to be different from the environment used during the development. This confirms that bots are configurable as they move from one environment to another and don’t have hard coded URLs, application paths etc.
• Code review is conducted to make sure development best practices like DRY (don’t repeat yourself etc) have been followed
• Any pop-ups, message boxes that were added as part of the development process are removed
• Any application paths, input and output file locations required by the bots have been created and access to these locations has been tested
• Access to applications and systems that bots are going to access has been received
• The runner machines have been tested to confirm the applications are accessible from the runner machines
• Any installed application that bots use for processing need to be installed on production runner machines before the first production run is scheduled.
• Run-book for production support of the bots is reviewed and a production handover meeting is scheduled.
• Bot execution schedule is reviewed and finalized with process SMEs

As part of the production cut over, the following points need to be taken care of:

• All bot dependencies are mapped and migrated as part of the cut-over process
• Hand over meeting with production support team is conducted
• Production support team is part of the first execution (HyperCare) of the bots in production
• Bots are scheduled and executed by designated bot promoter/ production support team only to maintain delineation of duty