The general question posed by industry experts is, “How do RPA Bots continue to work after production?” How should post-production changes/issues be handled?

A support Model collects all of the information in one location, such as What has changed? When will it change? How does it function? Are there any risks or issues to be aware of? All of these details must be communicated to business.

This is an important activity that must be carried out correctly.

With a simple step-by-step process, I will help you understand RPA Production Support in this post.

What is RPA Production Support?

The production support/maintenance team’s focus is to proactively identify any negative scenarios and provide a quick fix to any issues that arise, as well as handle incidents caused externally by system or network errors and updates.

All automated processes are maintained, monitored, and secured by the production support system. It ensures that your automated and mission-critical processes run smoothly 24 hours a day, seven days a week.

The Production Support team is explicitly responsible for ensuring that bots are scheduled and monitored according to the plan agreed upon with process SMEs.

This ensures that appropriate controls are in place to prevent unauthorized bots from running in production. The production support team is in charge of:

Bot scheduling and monitoring in production
1. Collaborating with IT infrastructure teams to ensure the availability of automated business processes and the resolution of any issues affecting bot execution.
2. Create a dashboard that displays bot execution results.
3. Collaboration with business SMEs for process exceptions or bot failures
4. Make the best use of runners (licenses) by effectively scheduling the processes.

RPA Support Services

Governance:

• Ticketing platform and Level 1-3 support — RPA projects must be defined in the same way that any other application project is. Support levels must be defined, and the service ticket model must be implemented. In general, an L1 support person is responsible for monitoring and very basic issues in production and should understand the process. Basic bot maintenance, password reset, starting or stopping the job, scaling up or scaling down the number of bots are some examples. To resolve issues, L2 support requires more technical expertise. Typically, developers with prior knowledge of the use case and flow are required to analyze and provide solutions. For instance, analyze the current issue and find a quick workaround for processing, or make minor changes to the flow due to additional data or an exception condition. L3 support is required when major process flow changes occur. Change’s impact on overall flow and architecture, for example. It necessitates a more in-depth analysis of the problem, and the solution must be discussed and approved with the client before implementation.
• RPA should be a stakeholder in the application change process, and any changes to the application UI should be communicated to the RPA team. The RPA team should make the necessary changes and test them with the application team before implementing them in production.
• Roles and responsibilities should be established for all members of the support and development teams.
• Budget for resources — The amount of money needed for support must be calculated and budgeted. This allows management and the RPA team to concentrate on support activities.
• Estimation of resources -One support resource for 6-8 production business processes. As discussed in the previous point (Points to Remember — for Support Resources), there are a number of tasks that support resources must complete.
• Change Requests vs. Support Activities — Business will have regular support needs, such as small changes to configuration updates. There may be a request to add some additional functionalities or requirements. These should be handled as change requests rather than support requests.
• Additional exceptions that were not communicated during the requirements gathering process should be treated as a change request.
• Undeliverable requirements should not be included in support, and the PM/scrum master should consider this separately.
• Process documentation — All PDD and SDD documentation should be complete. Any change requests or new functionalities should be added to the document.

Handover Documentation:

Once development is complete and the bots have been successfully deployed, the development team transfers the bots to the support or operations team. The following information should be included in the Bot handover document:

• Date of Publication
• Stakeholder involvement and BOT approval
• Design and functional documents
• Overview of the Access Required Code
• Schedules for BOT runs
• Troubleshooting steps, such as log location, execution reports, job reprocessing steps, and so on, should be explained.
• Process restart steps — If a process fails during execution, the steps to clean up and restart the process should be determined ahead of time.
• How do I activate the bot?
• Plan for Installation and Deployment (config, environment setup, files location, log file location, share folder location)
• BOT escalation procedure Specifics about the application interface
  Resolving Known Issues
• Platform for Ticketing

Why RPA Production Support/Maintenance structure is required?

A thorough support structure service ensures that automated processes run as efficiently as possible. RPA maintenance service ensures critical processes remain operational.

• In the given SLA, address all configuration/application level changes.
• Propose a Support governance model to handle all integrated application releases.
• All service requests must be addressed within the SLA.
• Reporting capability to highlight the reason for transaction execution failure due to various system-level validation.
• Regularly provide weekly robot execution status reports.
• Over the weekend, we provided 245 dedicated on-site support as well as phone and email support.
• In the given SLA, I handled all configuration/process level changes.
  Incident Resolution with complete resolution of P1, P2, and P3 tickets within defined SLAs.
• All service requests were successfully completed within the timeframes specified.
• Proactive release impact assessments are performed to identify field-level changes in applications and to prevent bot failures.
• Customer satisfaction of one hundred percent.

Types of Issues in Production

I’ve listed the most common production issues, which are related to infrastructure, applications, and bots.

Concerns about infrastructure

• The share drive has been disabled.
• VMs that aren’t responding
• Bot Runner is unable to connect to Orchestrator Control Room because it is unavailable.
• The Bot Runner machine will not boot.

Problems with application (global)

• The application is experiencing latency issues and has crashed.

Problems with the BOT

• Changes to applications (screens, controls, etc.)
• Problems caused by incorrect data input to the BOT for processing

Issues Stakeholders

GST (Global Support Team): Infrastructure and application support teams involved in RPA

RPA Support Team: Internal Robotic Process Automation support team-  The team consists of one architect or technical lead and one developer who are in charge of moving projects to production and supporting post-production.

Platform Global Support – Global Platform Support Team (Automation Anywhere, Blue Prism, UI Path e.t.c.)

Production Support Workflow

RPA Support Team Best Practices

1. Ensure that proper logs are kept at the transaction level while developing BOT.
2. Logs can be kept in CSV file or database, from which team owners can create a dashboard to track transaction progress.
3. If a BOT fails to process a transaction, an email is sent.
4. To handle errors such as screen changes, always use Error handling.
5. Nothing should be changed directly in production.
6. Before making any changes, make a backup.
7. Ensure that all tasks are properly versioned.
8. Obtain any necessary permissions from the client.
9. Aware of the client’s security compliance.
10. Continue to monitor jobs, robots, and newly fixed bugs.
11. If necessary and permissible, take screenshots as evidence.
12. If any Bot experiences downtime, communicate with the client and stakeholders.
13. Suggest an alternative solution to the client if one exists.
14. If the resolution is taking too long, keep the client updated on progress and complexity.
15. If you need assistance from the Product Team, inform the client so that you can get more time.
16. If you need to share logs with people outside the client environment, make sure you follow client data security procedures.

Summary

I hope you found this post on RPA Production Support useful and that you found what you were looking for. Please distribute it to your RPA colleagues and RPA network.

Want to learn more about providing modern support for automation bots?