Once the automation/technical team completes the development and testing of the Bot in the UAT/testing environment, it’s time to deploy it in the production environment. Make sure your technical team is following all the procedures already in place for testing and development of the Bot so that a quality solution that meets the expectations of the business goes into production. To move or deploy the Bot in production, a detailed and accurate procedure should be followed to avoid any unexpected issues while deploying. In this chapter, we will go through in detail everything you need to know about the deployment of the Bot to production, how to manage and support it once it’s in production, and how to retire the Bot whenever that is required. This will prevent any unpleasant surprises during the whole live life cycle of the Bot.
In addition to these topics, we will also discuss auditing and performance improvements of the Bot.
Solution (Automation/Bot) Deployment
Now is the time to operationalize the work you have done. You have received approval at each gate; updated risks, ROI, size, etc.; and designed and created the solution. Now you are ready to put the Bot in production.
Some larger organizations have a Center of Excellence; many do not. The term COE means different things in different companies, and the functions may be performed by the COE or the technical team. So when we refer to the COE, please remember that it may have a different name in your company or may not exist at all.
This organization, whether a COE, another group in your company, or the technical team, will have ultimate responsibility for deploying the new Bot. It will assure that the scheduled date can be met and that any associated applications will not be compromised by the new Bot and will monitor performance with the RPA team.
For any RPA program, there are many functions required; remember, they may be performed by a Center of Excellence or similar team, or by the technical team. You must consider the architecture of the robotic operating environment (infrastructure support, technology choice). Also, RPA operations (maintenance, support, monitoring, training of new resources, change management) are vital to know. What will your governance model look like? This includes integration to overall organizational structure, oversight of resources responsible to support all functionalities of the RPA program, compliance to policies and procedures, security system access, process prioritization, and the escalation path.
You need to know the delivery (process discovery and assessment, solution design, testing, deployment, development of standards).
In addition, the COE, if there is one in your organization, among its other responsibilities, maintains all the common functions required for RPA for the various lines of business. This makes management of the Bots simpler and more cost-effective. The COE also establishes standards and best practices and fosters continuous improvement.
We have said a lot about the Center of Excellence and acknowledged that there may not be one in your organization. We have also detailed, and will continue to discuss, the role of the COE. Who in your organization would be responsible for these tasks? Remember, it might not be one group, but the work may be distributed over several groups or individuals.
As you can see, early involvement with the COE will greatly assist you in deploying Bots on time and effectively.
The COE is also vital in managing access management and security. The COE assures that the Bot only has access to the resources (applications, systems, etc.) that are required for that particular automation. User IDs and passwords expire periodically, and the COE assists in renewing them as required. This differs from other application management functions, and it’s important to be aware of these differences when rolling out your RPA initiative.
Because the RPA program in your organization will evolve quickly, the COE enables the build of the new infrastructure and the adoption of new automation tools.
Many organizations, however, do not have a formal COE. If that is the case for you, the same functions must still be accomplished, but they will be performed by the technical team.
When we say “technical team,” we refer to the broader team beyond just developers. This can include such roles as process analyst, architect, business analyst, infrastructure analyst, developers, asset management, security, etc. What roles comprise the technical team in your new RPA program?
The technical team will work closely with the business partner who has requested the automation. The same tasks – establishing standards and best practices, continuous improvement, security, access management, etc. – must still be performed, but the technical team will take the lead on each one.
There are both advantages and disadvantages to having a COE, so you shouldn’t feel at a disadvantage if you don’t have one.
When there is no COE or equivalent group in the organization, the technical team takes over all responsibilities of COE. Less communication is required as it will only be between technical team members now. Faster action and quicker response times can be achieved. The technical team makes most of the decisions, and support and maintenance needs less management since there is no additional communication and collaboration required with any external team or department. The technical team can establish processes according to their own specific needs and improve or modify them in a timely manner.
Where there is a COE, it must follow organization guidelines and generalize the processes and standards. These may be less suited to individual teams, and they may need to be modified or updated to accommodate the requirements of a particular Bot/team/department. So while there are certainly advantages to having a COE, there can be drawbacks.
If your organization has a COE, do not attempt to bypass it, even if you think it will expedite deployment. This will cause a wide variety of problems and could potentially sink your RPA program.
- 1.Process setup for deployment and release.
- a.
Prerequisites for deployment: Sizing of the Bot(s), etc.
Before deploying any Bot, there is a wide variety of information that must be determined and shared with various parties. These include information about
The size of the automation. It could be the number of files, any database scripts, or other settings like scheduling, frequency, and number of Bots required. Sizing can be done on the basis of many factors. It could be based on the number of Bots needed to complete the work in the specified time, for example, if work can be completed in two hours, only one may be required, but if the same work needs to be completed in thirty minutes, then four or more Bots may be required. The size may depend upon the complexity of the automation or the steps that need to be automated, if they are complex in logic or must interact with multiple applications at the same time; this adds complexity to the automation, so more control over the Bot is required.
Size can be categorized as small, medium, or large. This categorization can be determined by many factors. Preliminary understanding will be obtained in the earlier phases. As you gain more information about the process, you will define the size.
The factors that determine size include the number of process steps being automated, number of systems accessed, volume of work, etc. Note that at this point, you know if it is “small,” “medium,” or “large.” As you have progressed through the process and gained more information, you now are able to definitely say the automation’s size. During “opportunity assessment,” you will determine a high-level understanding of sizing, but true size will depend on solution and scope that would be finalized at solution architecture.
Remember, don’t be too concerned about getting the sizing exactly right. These are general terms.
Pause and Consider For each organization, small, medium, and large will depend on the factors included herein and your own organization. What would constitute “small,” “medium,” or “large” in your organization?
In addition, the Bot could be attended or unattended. “Attended” means that someone is watching the execution of the Bot and observing it while it is running. This is done so action can be taken should the Bot error out. An attended Bot is always attended.
An “unattended” Bot will still be observed during deployment, but once the operational aspect is shown to be successful, it will no longer be “attended.”
Another piece of information is the scheduling of the Bot. How many times will the automation run each day, week, month, or even year? Or will it be “on demand”? This information was determined early on, when the purpose of the request to automate was initially received.
The volume of work that the Bot is expected to handle is also vital. If the work is stable and doesn’t change the period of time that the Bot will run, it will be simpler, but if volume may change significantly from run to run and there is no information or pattern or historical data about the work, then this must be carefully documented. Having historical information (e.g., the volume is usually doubled during the first three days of the month) will greatly assist in deploying a successful Bot.
It is necessary to verify the access to be used by the Bot in production; this includes the environment, user IDs, application access, and network access.
Verify that the emails are correct for communication. For example, if the Bot is to send those exceptions (situations that enter the process that, for any of a variety of pre-identified reasons, cannot be handled by the Bot) to a specific email, assure that the address is correct.
If the Bot is an update or enhancement to an existing automation, you must plan for disaster recovery. In the event that something goes wrong with the update or enhancement, you need to be able to quickly return to the Bot prior to the update or enhancement, so at least the work that had been processed can continue to be.
- Any software version has three parts:
Release number (sometimes referred to as “major version number”): For a new automation, the release number will be one (1). Release or major version numbers also change whenever there is some significant change being introduced. For example, a large or potentially backward-incompatible change to a software package.
For enhancements, including adding steps of a manual process into the automation (remember, the initial automation may only have automated some of the manual steps; at some point, additional steps may be automated using the same Bot), the release number would be incremented by one.
Minor version number: Minor version numbers change when a set of smaller features is rolled out within the Bot.
Patch number: Patch numbers change when a new build of an existing Bot is deployed. This is normally for small bug fixes or updates to templates, etc., used by the Bot.
An example of a number would be: 1.002.013. This indicates that it’s the original release (or major version), there have been 2 minor updates, and 13 patch changes (bug fixes, template updates, etc.).
Identify the specific people (not just the roles) in the business, and the SMEs, who must be present at the time of deployment.
Pause and Consider Throughout this book, we have specified identifying roles, not names of individuals. Now we are specifying individual names. This is because at this point, you need to know exactly who will fulfill these responsibilities.
If your organization has a COE, determine the specific person or people from the COE who will be present during deployment. This should not be at all difficult to determine, because if you do have a COE, you have been interacting with that group from early in the process.
Validate that all project and/or folder structures are consistent with all guidelines on production automation tool being used.
Assure that all applications and systems are accessible from the production environment (URL, network, etc.) by the Bot user ID and any other user ID used for the application itself.
Ensure that the infrastructure is capable of adding new automation and Bots according to the schedule.
What are the risks? At this point, all identified risks must have a mitigation plan, with a role assigned to it. The mitigation plan may be simply accepting the risk, but there needs to be a role assigned, so that if that risk event happens, that person can be contacted to see how they want to handle it.
- b.
Instructions and documentation for deployment: As indicated by the paragraph and lists earlier, there is a lot to do to ensure a smooth and successful deployment. In order to accomplish this, there need to be detailed instructions documented for the specific deployment. While the items in the bullet list mentioned previously must all be achieved, each automation will have tasks specific to it. These include preparing a transition to production form and sharing it with COE if there is one or with the pertinent members of the technical team if there isn’t. Please refer to transition to deployment form.
- c.
Release options (pilot release): When the automation or the Bot is large and complex in nature, and is business critical, then you can choose to deploy the Bot in a constrained manner instead of going full live. There are many options that can be tried or adapted. This technique is also called pilot release.
There are various pilot release options. These include
– Single Bot only: If the Bot has to release with multiple Bots, for pilot release, the Bot can be single so that if errors occur, they can be handled properly. Sometimes if the full release of the Bot is single, then restricted mode can be adopted.
– Restricted mode: In restricted mode, very light work is assigned to the Bot in the first few days, and performance is watched.
– Ghost mode: When the work done by the Bot is visible to end users or has a big impact on the business (e.g., there are dependent services on the work or updates done by the Bot), it is preferable for it to be validated prior to being delivered to the end user during the warranty period (more about warranties later). This can be done by diverting the output to some other area of the system or another environment (email to a member of the technical team, creation of a report, etc.). If the outcome is what is expected, the Bot is rerun in the production system but not in ghost mode.
There are no hard and fast rules; it all depends upon the situation and how the outcome of the Bot is to be captured. All these factors must be considered prior to a pilot release so they can be effectively managed.
- d.
Negotiate deployment/release dates with the business: Often, the person requesting the automation wants it yesterday! During the initial discussions (see Chapters 4 and 5), you and the business owner and SMEs have come to a mutual understanding about a realistic date. This is seldom one specific date and is more likely a range of dates. For example, the business, in conjunction with the development team, decides that a reasonable date for deployment is between May 15 and June 8, 20xx.
This information would have been conveyed early on to the COE, if your organization has one. If not, your regular contacts with the business and with people responsible for the systems and applications you must impact would have been kept informed about the date range, assuring with them that it was reasonable.
Now it is time to finalize the dates with the business. You have far more information now than you did in earlier phases. You know the upstream and downstream systems and applications to be impacted. You know what needs to be done for deployment, and now you can use this information to nail down a specific date with the business owner.
If your organization has a COE, that group has been a third partner with the technical team and the business and now must be included in determining the release date. The COE would have been advised of the range acceptable to the business and technical team as early as it was known. If, at that time, the COE said that no date within that range was possible, you would have gone back to the business to renegotiate. Now it is time to work with the COE and the business to determine the date of deployment.
- e.
Warranty: When the organization has a COE, the warranty time is provided by the COE after deploying the Bot in production. In organizations without a COE, the warranty is handled by the technical team. Usually, the warranty is set for two weeks, but the dates of the warranty period are flexible. For very simple Bots, it could be only for one week, but decreasing the warranty period is the decision of the business and technical teams. Similarly, for very complex Bots, the warranty can also be increased to three to four weeks. Again, increasing the warranty is not something that happens very frequently, but is agreed to among the business, technical team, and COE (if there is one). This depends partly upon the resources required to provide service during the extra period and their availability.
It is also advised that in these situations, if there is a COE, it should be made aware of the extension as early as possible, so that they have sufficient time to be prepared.
Major Steps for Deployment
As you prepare for deployment, you must assure that the scheduled date for deployment has been agreed to by all stakeholders. Also, be sure that all required documents are signed off for the deployment process. This includes all documents required by compliance: requirements documents, code review, and test summary. Stakeholders include the release or delivery manager and the business product owner. There may be other stakeholders in your organization whose sign-off is required.
You will then package all the code files and create database scripts or any Bot scripts (depends on the automation tool being used) and any and all Bot documents (e.g., Read Me files).
Some software tools allow the user interface to deploy Bots to production environments from stage or UAT environments. Check if the automation tool used in your organization provides the user interface for moving files from the UAT environment to the production environment.
You will need to share all required files (all those files created in the step mentioned earlier) and pertinent documentation with the deployment team. This could be through network share, email, or the automation tool itself.
Some software automation tools may offer to build scripts, and those scripts may be invoked manually or via other means to deploy Bots. Again, you need to check if the automation tool that you are using provides the user interface for moving files from the UAT environment to the production environment.
As you approach deployment, schedule a meeting with the deployment team members to block their time for the time agreed upon for deployment. You need to assure that they are available for the deployment.
You will now deploy all files to production and run scripts on the database if required. Once all files are shared with the deployment team, all files will be copied to the production environment, during the time scheduled for deployment. Validate that all required scripts have been run.
Bots can also be deployed by physically copying code files to the production environment and changing the required databases as per requirements. As stated previously, you need to determine if the automation tool that you are using provides the user interface for moving files from UAT environment to production environment.
You will schedule the Bot as per requirements (e.g., hourly, daily, weekly, working days only, etc. This was decided earlier in the process). Then you will test run the Bot in production if required. This assures that the Bot is working properly in production, because the environment is new. The production environment may be different from the test environment. After that, you will validate the results to assure the Bot is working properly and then announce the successful deployment to the business team.
Deployment steps vary with the software automation tool that is being used for implementing RPA in your organization. What changes will be required in development in your organization, depending on the tool you select?
The technical team will continue to monitor the Bot for a few days as agreed to with the business (and COE if there is one). This is for new Bots. For upgrades or other changes, the technical team will only monitor for one run, or one day, depending on what has been agreed upon.
We have provided a long list of items to do prior to deployment. How will you remember to do them all? The best way to avoid having anything fall through the cracks is to use a checklist. The following is a sample (this is also included in Appendix 11 for your convenience).
Deployment and Release Setup Checklist
Item | Item Details | Comments | Status* |
|---|---|---|---|
Product (Bot) Name | Provide the name used to refer to the solution/automation. This name will be used in inventory, reports, change requests, etc. | ||
Deployment date and time if applicable, agreed upon | As per project plan, provide the planned/preferred date for the deployment. | ||
Size of automation | It could be small, medium, or large. | ||
Bot schedule | Specify the preferred schedule (times and days of the week). The acceptable range of start times for the Bot. The approximate runtime of Bot. Are there any service-level agreements associated with the process that affect the scheduling of the automation? | ||
Contacts during warranty | During warranty, the deployment team may need to contact a software developer on the delivery team that is familiar with the code. Ensure that the developer will be available for five business days after the deployment date. | ||
Statement of segregation of duties | Delivery team will note names of software developer(s) who wrote the code. Automation services will note names of who user acceptance tested the code and who on automation services is deploying the code. To ensure segregation duties, automation services will ensure that The software developer who wrote the code was not the same person who performed user acceptance testing. The deployer of the code to production is not the same person who wrote the code. | ||
Volume of work | What is the expected number of items to be processed by the Bot in a designated time period (daily, weekly, etc.)? | ||
Access verification | Mention what type access is required and has it been verified in production environment. | ||
Email addresses for communication | Emails of business and technical contacts those will be contacted for any information, errors, or other reasons. | ||
Disaster recovery | Backout steps, post-implementation steps. | ||
Major/minor version | Specify if this is a small change to an existing Bot or a large, significant change. | ||
People who will be present at deployment | List the names and roles of the people who must be present at the time of deployment. | ||
COE contact | List the name and title of this person. | ||
Folder structures | List any new folders required. | ||
System/application accessibility | Document any known issues. | ||
Infrastructure capability | Document any known issues. | ||
Risk identification and roles responsible | Summarize this from the risk assessment. | ||
Deployment instructions/steps Task Deploy Steps Pre-implementation steps Implementation steps Test the implementation steps Backout steps Post-implementation steps | Provide a detailed playbook for the deployment. Typically the automation services deployment manager specifies the implementation and backup steps. | ||
Communication channels established | Specify them. | ||
Production Support Model | Are you retaining break-fix responsibilities for this automation? If yes, provide remedy support queue name and email contact for the business technical support team. If no, automation services will engage the development team as part of the D2P process to ensure a smooth transition to maintenance knowledge transfer. |
“Status” could be “complete,” “incomplete,” or “not applicable.” For “incomplete” or “not applicable,” be sure to include a brief, explanatory comment.
Maintaining Communication Between COE/LOB and Dev. Teams for Deployment
We have mentioned that your organization may or may not have a COE. If there is one, it is vital that you work with the COE throughout the process of the automation initiative. There must be efficient communication about coding standards, code review standards, upgrading the automation tool, and deployment schedule. It is the responsibility of the technical team to set expectations. What is the date (range) that the business wants deployment to fall within? Will any infrastructure upgrades be required? What development environment will be used?
The COE, if there is one, defines who will maintain the development environment and who will maintain the Bot. Some might be maintained by the COE, some by the development team. If there is a COE, it maintains the execution of the Bot.
The technical team has the contact with the business, so the technical team has a greater role in collaboration and communication during maintenance. If the Bot didn’t run, the business will contact the technical team, which will then, in collaboration with the business and the COE (if there is one), determine the next steps. This could be reverting back to the manual process until the Bot is repaired, rerunning the Bot once work is available, or stopping the Bot and restarting it when the business determines it can be restarted. Rerunning the Bot depends on the SLA; rerunning options are usually decided as part of deployment planning. We will look at some examples:
- 1.
Stopping the Bot: The Bot could be stopped and the process performed manually, until the repair is made. Then the Bot begins again with the new, incoming information.
- 2.
Rerunning the Bot: Perhaps the Bot didn’t run overnight as scheduled. In this case, it could simply be run during the following day with someone monitoring it to assure that it runs.
- 3.
Stop and start: If the Bot isn’t performing as expected, and it is due to the load that the Bot is processing (needs some tweaks or updates), or if the manual process needs some changes, then the Bot can be stopped and the necessary changes made. For example, Bot is processing Jira cards (they are the input for the Bot), and the manual process steps to be executed before the Bot begins have not been completed (e.g., Jira cards have not been updated or otherwise set up per the Bot’s requirements), the Bot can be stopped until the required work in the manual process is complete. Then the Bot can be restarted.
Level 1 support is done by the COE: changing the schedule, changing the frequency of run, changing the number of Bots running at one time, updating user IDs and passwords, changing the priority of the Bot, and including/excluding any email IDs that need to be contacted in case of information from the Bot. All changes and updates which are not impacting the actual running of the Bot from the technical side. Example: Bot is running fine, but some changes in the settings of the Bot are required. These are nonfunctional requirements.
Level 2 support is done by the technical team: when the Bot is not performing as per requirements/expectations. This pertains to functional requirements.
In the absence of a COE, both Level 1 and Level 2 support are done by the technical team in collaboration with the business owner.
Maintenance of Bots
3.1 Setup and manage the support queue.
- a.
Agile : Dev. team rotates the term (weekly?) for on-call support and will respond to COE/LOB contact about malfunctions. An inbox may be established to report on Bot performance and exceptions. This is monitored by the Dev. team member designated for the particular week. This allows all the team members to be familiar with all the Bots. In a more traditional methodology, one or two members of the technical team are assigned to the support queue, although a more rotational support may be implemented to increase team members’ knowledge of all the Bots.
While setting up the support queue, steps between the COE and the business should be very clear. This includes when an incident is reported to the technical team, it is determined: should the Bot be stopped; who is the contact on the business side for that particular Bot; can the Bot be rerun (decided in advance that it will be rerun every time, or will that be an individual decision); will it be stopped immediately every time; etc.? For some Bots, it is known that the business wants it to run again if it fails.
A short description of “next steps” can be done for every Bot to ensure quick action for any incident reported. This will greatly assist anyone who is assigned to support at the time of the incident. Steps may be: contact the business; stop; rerun (with information about how much time to wait before rerunning: immediately, after X hours, the next day, etc.); let it run and update the business regarding the issue; etc. This “next step” document is shared with the COE, business, and technical team. These are the immediate first steps.
It should be very clear to everyone on the team that the person on the call isn’t responsible for resolving the issue. That person is the contact person who will coordinate the response with the business, COE, and technical team. If the person on call is not able to resolve the incident, the person who is expert on that particular automation can be engaged.
In RPA, the technical team is comprised of several different roles (process analyst, architect, business analyst, infrastructure analyst, developers, asset management, security, etc.).
If your organization has a COE, Level 1 support is maintained by COE, and Level 2 support is taken care of by the technical team. In the absence of a COE, both Level 1 and Level 2 support are the responsibility of the technical team. Once the Bot is deployed, Level 1 support starts monitoring the Bot.
3.2 Monitoring the Dashboard
After Bot deployment, it must be maintained to assure it is doing the work it was created for and that its performance is at an optimal level. Continuous monitoring is vital. Monitoring can be automated or manual. Automated monitoring could include sending alerts, such as emails or text messages, that advise if the Bot is underperforming or has stopped working or by updating dashboards.
Dashboards are very handy for monitoring Bots. Most of the automation tools come with simple dashboards that can easily be configured for deployed Bots. Dashboards are easily accessible via user interface by the technical teams or business partner to keep an eye on the real-time status of the Bot and how it’s performing. As Sharda Cherwoo and Roy Rachamimov have said, “The operational dashboard is vital for the day-to-day running of the bots - monitoring their activities frequently and in real time. At the early stages in an RPA’s program, there are few bots and all the attention is on integrating them into workflow and making sure they complete their tasks successfully.”1 (Note: for more information, please see the article referenced in the footnote.)
Prioritization
This is when many Bots need to be rerun. For example, servers on which the Bots are running are down, and as a result, there are many Bots to be rerun. Prioritization will come from the business owners, determining which will come first. Some Bots are processing business-critical work (e.g., satisfying regulatory requirements).
In the case where there is no business-critical Bot to be rerun and all the Bots have the same priority, it is the decision of the COE or tech team. They can decide to run first those that are very short or have a small amount of work to get those completed. More complex Bots that will take more time to run will then be run. The guidelines for prioritization should be established up front, but should be sufficiently flexible to adapt to differing or varying situations .
Warranty
Whenever a new automation is deployed to production or a new release is moved to the production environment, there is a warranty period assigned to the Bot.
The warranty period could be of one week or two weeks as per agreement between the business and technical teams. Bots take time to stabilize and there might be some issues initially with new Bots. So the warranty period allows for the solving of defects quickly fixed with minimum dependency on multiple people. During the warranty period, all the documentation required to move the Bot to production, such as business sign-off, testing sign-off, etc., is not required. The fixes are done quickly to keep the Bot running. As mentioned earlier, the warranty period can be extended if either the business or technical team feels that the Bot needs to be closely watched for a longer period of time.
Bot Categorization
Bots can be “critical” or “noncritical.” Critical Bots are those which are time critical; their output may be required for government regulations. These Bots have a significant impact on the business. If a critical Bot fails, the technical team must be able to take action immediately, without waiting for a decision from someone else to do so. For critical Bots, all the actions to be taken in case of failure must be defined prior to deployment.
Noncritical Bots do not have the same impact on the business. In case of failure of a noncritical Bot, advice from the business is required before any action is taken. The business will decide whether to rerun the Bot or take some other action. The technical team will respond accordingly.
Communication
In Chapter 5, we introduced the need to be in communication with your company’s COE (Center of Excellence), if there is one, or, if not, with the department that will be responsible for deployment. Now that you are about to deploy, the relationships you established earlier by involving this group and letting the people there know what was being deployed, when deployment was desired, and other pertinent details, will greatly assist you in getting the Bot up and running when required.
In earlier phases, you advised this group (or individual) of the process being automated, what systems it would interact with, how often it would run, what platform it would run, and other pertinent details. They knew what date you wanted deployment and have, hopefully, worked to assure that everything was in place on their side. You need now to update them on a variety of issues, since things can change from day to day. Here are some of key topics to confirm:
Business unit requesting the automation
Requested date
Impacted systems
Date of Governance Committee meetings
Any changes that the business might ask for after the additional request
Anticipated size of the Bot (number of steps being automated, volume)
Frequency of run
Others as may be required by your team and the particular Bot being created
Change Management
When Bots run, there are always issues, and change management is used to fix, deploy, and keep track of them. Tracking of changes requires the creation of change tickets so that the work can be documented and tracked. There are many situations where different types of actions to fix a problem are required. As a result, change requests can be categorized to facilitate the team in taking the correct actions.
Tickets can be categorized as a change request, a service request, an investigation request, or a general request.
A general request is created when information regarding any Bot is required, such as the total work done, when the Bot started or completed, etc. For these types of requests, there is no need for any approvals since they are informational requests only. There is nothing immediately to fix change. These requests are triggered by the receipt of any alert produced by the Bot. The information is provided to the technical team for review.
Following the review of the information provided by the general request, either an investigation request or a change request may be created. An investigation request is created if additional resources are required to further explore the issue and find its root cause. In most cases, the Bot performed fine in the test environment, but isn’t performing as well in the production requirement.
Some general requests may trigger a change request. The technical team may receive a general request as noted earlier. If they are able to identify the issue and the root cause, and they can implement the fix, a change request will be created. Following approval of the change (generally done through email), they can update the Bot code files.
These are the types of requests that are generally used, but it depends upon your organization’s needs. How do you think you should categorize tickets in your new RPA program? If you are unsure, use what we have here; your program will evolve and you will learn over time if these categories best suit your organization’s needs.
Having too many categories of tickets makes it difficult to understand and manage expectations, and it can become difficult to discern one type of ticket from another.
Auditing Bots
Once the Bot is deployed and is doing its work, we start collecting information about Bot performance. There is much information to glean.
How many work items a work is processing in X amount of time? The expectation will have been determined earlier in the process.
What is the workload the Bot is receiving every day? When the request was initially made, an estimate of the workload was provided. This probably changed as you learned more about the process, and now you will see what workload the Bot is actually receiving.
How many times does it error out during the day? This indicates that an error has occurred; the Bot may continue or stop, depending on the error. Sometimes the Bot will encounter an error that it can move beyond, but sometimes the error will cause the Bot to stop. Depending on the error, the Bot may try to process it again.
On-time starts vs. delayed start. This includes how many times the Bot starts on time, and if the start is delayed, how long was the delay. It also includes whether or not the Bot completed the work if the start was delayed. Knowing this information may lead to rescheduling the Bot start time.
For complex work items with many steps, information is collected on sub-items between the works. This means looking at the individual steps at the smallest level and determining where the issues causing problems exist.
Once this information is gathered, it can be analyzed and verified where the Bot is taking more time than expected; if erroring out too frequently, or infrastructure is slow, or applications are slow, these can be analyzed and addressed.
As noted in Chapter 4, an initiative could be a new Bot, an enhancement to an existing Bot, or defect correction. Deployment to production is slightly different for each case. Most of the information in this chapter refers to deploying a new Bot.
For an enhancement, a lot of the required information will already exist. You will generally know the systems and applications that the Bot accesses, and an enhancement will probably use the same ones. If there are changes, they will be noted. An enhancement often includes automating additional steps within the process; for example, if a Bot automated steps 3–9 of a process with 15 steps, perhaps additional steps are requested to be automated. The process is already known, so that need not be documented again. So the deployment steps are basically the same, but are expedited because so much information is already known; you are just building on what already exists.
This doesn’t mean, however, that all identified risks need not be mitigated or that business doesn’t need to sign off on the enhancement. But many things for deployment will already be in place from the original deployment of the Bot.
Defect fixes can be deployed by simply assuring that so doing won’t “break” anything that is working. Testing sign-off is required, and then the fix can be put in production.
If the defect occurs outside of warranty, testing sign-off and approval of updated requirements may be required. This depends on the standards set in your organization, but both approvals are recommended.
Disaster Recovery
This is the plan required should the Bot fail to do the necessary work. This could occur because servers are down, the Bot is working too slowly, or applications that the Bot is using are unavailable (e.g., Bot is using Jira, but Jira is unavailable). In these and other related cases, the functions of the business must continue. The disaster recovery plan, detailed in the SDD (see Chapter 6), is the blueprint for use in these emergency situations.
If there is a COE, that team will notify the technical team that a Bot is not working. In the absence of a COE, the business or the technical team itself will identify the problem due to its monitoring of the Bot, or the business may notify the technical team. The technical team and the business will decide to either run the process manually or wait until the issue that the Bot has encountered has been resolved and then rerun the Bot.
Retirement of Bots
One of the things that must be planned for is the eventual termination of the Bot. There are many reasons why a Bot may no longer be required.
Sometimes, the process is terminated. For a variety of reasons, the process may eventually no longer be needed. Perhaps through a merger, the purchasing company’s process has incorporated the work of the Bot. Or the Bot may have supported a service that the company no longer offers. There are many reasons for a Bot to be determined to be no longer necessary.
In some cases, the current process has changed so significantly that a new Bot is required. All organizations are constantly striving for improvement, and processes will need to evolve along with them. Adjustments to the Bot can certainly be made, but there may come a time when it will be more economical to terminate a Bot and replace it with a new one. This becomes a simple “dollars and cents” decision.
There are situations where the automation software is converted to another software tool. Sometimes it may be necessary to convert from one software tool to another. This could be because the existing tool is unable to meet the automation need, a less expensive tool has been located, or other reasons. The Bot will be “retired” for the existing tool and a new Bot built for the new tool. The new Bot may be the same as the retired Bot.
Despite all your careful planning, sometimes the Bot is simply not achieving minimum savings. During auditing, you will be able to see how effective the Bot is. Despite all your due diligence through the stages as detailed in the previous chapters, it’s always possible that the Bot simply doesn’t deliver what it was meant to. You may want to make some adjustments, but, even by so doing, you and/or the business may come to recognize that the Bot simply isn’t worth its expense. If your organization has a COE, someone from there will advise you that they have reservations about the Bot’s performance.
In this situation, you will need to work with the business (and the COE if there is one), to determine if some adjustments could be made that would improve Bot performance, or if simply terminating the Bot is the most cost-effective decision (please bear in mind that cost is not always the determining factor of keeping or terminating a Bot. If, e.g., it is providing a service that enhances the customers’ perception of the company, it may be advantageous to maintain it, even if doing so is an expense).
Steps to retire the Bot
Retiring a Bot is something that will be done eventually for most Bots. Initially, this will probably not be an issue, but as conditions and technology change, there will be times when a Bot will no longer be needed.
A request is received from the business to retire a Bot. The retirement of the Bot is the decision of the business. Information may have come from the COE that the Bot is not performing as expected, but the decision to retire it rests with the business.
Identify the stakeholders. This is required since many areas are probably dependent on the Bot; either they are responsible for providing information to it, or they receive information from it.
Collaborate by clearly stating which Bot is to be retired and which processes are impacted. It is vital that there is no question about the Bot being retired.
Determine when execution of the Bot will stop. This will be done in conjunction with the business and other pertinent stakeholders.
Identify any user IDs or access that must be terminated. Different roles may have been able to access various systems when the Bot was in operation, and now that access must be terminated. Please note that there may be cases where some or all of the access will not be terminated. Work with the business to know these situations. Be aware that if the Bot is being discontinued and the process it had automated will once again be handled manually, access to some or all of the systems may need to be available to individuals.
Determine alternative options for when it will stop doing the work. If the process is being discarded, no options are required. But if the process is going to continue but be performed manually, the business must have sufficient time to make the necessary arrangements and operationalize the manual process. This will probably have no impact on the RPA team, except in determining when the Bot can actually be retired.
Obtain the necessary sign-offs for retiring. These would include business representatives and the COE (if there is one).
Collaborate with COE (if there is one) to actually stop the Bot and release all user IDs and resources. If there is no COE in your organization, the technical team is responsible for stopping the Bot.
Officially declare retirement of the Bot. Send an email to all pertinent stakeholders, advising them that the Bot is no longer operational.
As shown, there are several reasons for Bot termination. Can you think of processes in your organization that may not be particularly profitable from a balance sheet point of view, but are still important? Be sure management is aware of any such processes that are being automated, so they understand that there may not be a huge financial advantage in the automation, but that it is important nonetheless.
Case Study
Now we will look at how these tasks would be performed in the hypothetical case study we have been following.
Item | Item Details | Comments | Status |
|---|---|---|---|
Product (Bot) Name | Phone and address update | This name will be used in inventory, reports or change requests, etc. | Complete |
Deployment date and time if applicable, agreed upon | Jan 1, 2022 | This has been agreed upon with all necessary stakeholders. | Complete |
Size of automation | Medium | Based on volume and frequency of run, we have determined the size as medium. | |
Bot schedule | Monday to Friday: 3 times of day 10 am, 1 pm, 6 pm | This satisfies the needs of the business as agreed upon by the product owner. | |
Contacts during warranty | John Smith Mary Jones | The developers named will be available during the warranty period to address any issues that may arise. | |
Statement of segregation of duties | Code written by Mary Jones Documentation Sarah Williams SME involved in UAT: Douglas Johnson and Betty Parker | The individuals named will be available as needed during the warranty period. | |
Volume of work | 100 cases for one run | ||
Access verification | Access verified for web application XYZ and for mainframe ABC | The developer named earlier has been granted full access to both the XYZ application and the ABC mainframe. This will minimize delays if problems arise with the Bot. | |
Email addresses for communication | Dev1@company.com | These emails will be used to provide the stakeholders with a daily update of Bot performance and to advise them of any issues. There will be once-a-day emails if there are no issues, but if issues arise, these stakeholders will be notified immediately at these email addresses. | |
Disaster recovery | Stop the Bot and inform contacts. | The business will decide whether or not to perform the process manually while the required repairs are made to the Bot, or whether to rerun the Bot after the issues are resolved. | |
Major/minor version | 1.0.0 | ||
People who will be present at deployment | John Smith | ||
COE contact | There is no COE. | Not applicable | |
Folder structures | No new folder need to be created | Not applicable | |
System/application accessibility | Application XYZ, mainframe ABC | Both are accessible by the required parties. | |
Infrastructure capability | Phone and address update Bot is available to execute. | Complete | |
Risk identification and roles responsible | All identified risks have been mitigated. | The business owner assumes all responsibility for any unanticipated issues that arise. | |
Deployment instructions/steps Task Deploy Steps − Pre-implementation steps − Implementation steps − Test the implementation steps − Backout steps − Post-implementation steps | Roger Adams, the Automation Services Deployment Manager, has specified the implementation and backup steps. These are documented in the form “Address and Phone Update Bot, December 1, 20xx,” available at “C/Business_Unit_123/Bot_Directory/Address_and_Phone_Update_Bot.doc.” | ||
Production Support Model | Both Level 1 and Level 2 support are the responsibility of the technical team | Automation services will engage the technical team as part of the deploy-to-production process to ensure a smooth transition to maintenance. This will include a thorough knowledge transfer. |
The checklist is extensive. It may be complete for your organization; it may have items you need not consider, or it may not have factors that will be important to you. Based on what you have learned about RPA, and your knowledge of your own organization, what do you think you might need to add to the checklist? What do you think can be omitted? If you are unsure, use it as is for your first few projects. Time will teach you what you need to change.
Now that you have deployed your Bot, we will look at organizational structure models. You will have used whatever the model currently is within your organization, but as your RPA program matures, you may want to make changes. Chapter 8 details the most common organizational structures.