RPA BOTs Post Production Support Mechanism
By: Amol Deshmukh
Tags: Support, Robotics, Rpa Tools, Automation, Rpa News

The generic question asked by industry experts is — how RPA Bots keeps on working post production? How to tackle post-production changes/issues?

A support Model captures all of the information in one place like What’s changing? When is it changing? How does it work? Any risks or issues to be aware of? All of these things need to be communicated with business.

This is one of the important activity and needs to be implemented properly.

Governance:

Ticketing platform and Level 1–3 support — RPA projects need to be defined as any other application project. Support levels need to be defined and service ticket model needs to be implemented. In general L1 support person deals with monitoring and very basic issues in production, should have understanding of the process. Example — Basic Bot maintenance, Password Reset, Start or stop the job, scale up or scale down number of bots. L2 support requires more technical expertise to resolve issues. Mostly developers with prior understanding of use case and flow need to analyze and provide solutions. Example — Analysis of current issue and find a quick workaround for processing, minor changes to the flow due to additional data or exception condition. L3 support comes into picture in case of major process flow changes. Example — Impact of change on overall flow and architecture, It requires more in-depth analysis of issue and solution needs to be discussed and approved with client before implementing.

— RPA projects need to be defined as any other application project. Support levels need to be defined and service ticket model needs to be implemented. In general L1 support person deals with monitoring and very basic issues in production, should have understanding of the process. Example — Basic Bot maintenance, Password Reset, Start or stop the job, scale up or scale down number of bots. L2 support requires more technical expertise to resolve issues. Mostly developers with prior understanding of use case and flow need to analyze and provide solutions. Example — Analysis of current issue and find a quick workaround for processing, minor changes to the flow due to additional data or exception condition. L3 support comes into picture in case of major process flow changes. Example — Impact of change on overall flow and architecture, It requires more in-depth analysis of issue and solution needs to be discussed and approved with client before implementing. List of Application Stakeholders — RPA should be a stakeholder in application change process, any change to the application UI should be communicated to the RPA team. RPA team should be making the required changes and should test with application team before these are implemented in production.

— RPA should be a stakeholder in application change process, any change to the application UI should be communicated to the RPA team. RPA team should be making the required changes and should test with application team before these are implemented in production. Roles and responsibilities setup — Roles and responsibilities should be setup for all support and development team members.

— Roles and responsibilities should be setup for all support and development team members. Budget for resources — Resource requirement for support needs to be calculated and budgeted. This helps management and RPA team to focus on support activities.

— Resource requirement for support needs to be calculated and budgeted. This helps management and RPA team to focus on support activities. Resource estimation –One support resource for 6–8 production business processes. There are number of tasks that support resources needs to do as discussed in last point( Points to Remember — for support resources )

–One support resource for 6–8 production business processes. There are number of tasks that support resources needs to do as discussed in last point( ) Support activities vs Change Requests — There will be regular support requirements from business or small changes to configuration updates. There may be request to add some more functionalities or additional requirements. Those should be handled as change request and not as support requirements.

— There will be regular support requirements from business or small changes to configuration updates. There may be request to add some more functionalities or additional requirements. Those should be handled as change request and not as support requirements. Additional exceptions not communicated at the time of requirements gathering should be considered as change request.

Undelivered requirements should not be part of support and PM/scrum master needs to consider this separately

Process documentation — All documentation PDD and SDD should be complete. Document should be kept up to date with any change request or additional functionalities.

H andover Documentation:

Once development is done and bots went live successfully, development team handovers Bots to support or operations team. The Bot handover document should include following details:

Release Date

Stakeholder involved and sign off

BOT Functional and Design documents

Access Required

Code Overview

BOT run schedules

Trouble shooting steps should be explained, like location of logs, execution reports, reprocessing of jobs steps, etc.

should be explained, like location of logs, execution reports, reprocessing of jobs steps, etc. Process restart steps — If any process stops during execution, what are the steps to clean up and restart the process, these should be decided beforehand

— If any process stops during execution, what are the steps to clean up and restart the process, these should be decided beforehand How to trigger the bot?

Setup and Deployment plan(config, environment setup, files location, log file location, share folder location)

Escalation procedure

BOT Application interface details

Known issues resolution

Ticketing Platform

Points to Remember — for support resources

•Do not change anything directly in production.

•Take backup before changing anything.

•Maintain proper versioning of all the tasks.

•Take necessary permissions if required from the client.

•Know the Security Compliance of client.

•Keep monitoring jobs, robots and newly fixed bug.

•Take necessary screenshots as evidence if required and permissible.

•If there is any downtime for any Bot, communicate with client and stakeholders.

•If there is any alternate solution, suggest it to the client.

•If it is taking too long to resolve, update the client with progress and complexity.

•If you are taking help from Product Team, highlight this to client to get more time.

•If you need to share logs to outside the client environment, please make sure you are following client data security compliance.

•Keep on updating about license expiry, password expiry and software updates.

•Keep monitoring memory and performance of the system.