This article is part of a broader series that forms the Automation Success Framework. Please click on the link to view all topics. Note that there is a considerable amount of interdependency between each of these topics. For example, your choice of model for the automation CoE will influence how you need to configure the Control Room, and will also influence the roles involved in the Automation Lifecycle.

In this article we will discuss the process of managing automations through the various stages of the automation pipeline or lifecycle. Note that a separate article deals with the configuration of the control room to support different DevOps practices and to manage separation of duties. That article is available here..  

Introduction

The stages through which automations will move should be considered as more of a lifecycle that a straight pipeline. This is because automations tend to evolve continuously as the operations of the business change. There are four key stages to the automation lifecycle, which are highlighted in the diagram below. The activities which must be undertaken in each of these stages and the roles of the people involved are discussed in subsequent sections within this document. Every automation should move through these four stages and have the key activities related to each stage completed.

Note that Automation Anywhere provide a solution called CoE Manager, which along with the Control Room, is used to manage your entire automation program. CoE Manager provides an end-to-end solution for managing the lifecycle of your automations and for reporting on the benefits delivered by the Automation Center of Excellence (CoE).

Stage 1: Discovery and design
 

In this stage the organisation will conduct activities to identify business processes which are suitable for automation. Each automation opportunity needs to be assessed to determine how feasible it will be to automate the process. The list of potential opportunities needs to be tracked and prioritised. Documentation of the process will typically be prepared to enable a bot developer to begin work on the opportunity when it is time to do so.

These activities are summarised in the diagram below and are discussed in more detail in the following sections:

Sourcing Opportunities

There are many ways to source opportunities for automation. Organisations with a mature automation strategy often assign the role of automation champion to individuals within each business unit. An automation champion will have a good understanding of the capabilities of the platform and will identify opportunities within their business unit. They are responsible for collecting enough information for the opportunity to be assessed for feasibility.

Another approach to sourcing opportunities is for the automation CoE to run process discovery campaigns. The first step in a process discovery campaign is to choose a business unit(s) to work with, and to then run an education session on automation and what makes a good automation opportunity. Then, over a certain time period, the members of that business unit(s) monitor their daily work for automation opportunities. They provide information about each identified opportunity in a template provided by the automation CoE. This provides consistent information to assess each opportunity.

The Automation Anywhere CoE Manager solution provides a configurable form for collecting standardised information for each automation idea. This form can be accessed by any employee and can be used in conjunction with any of the strategies outlined above.

Automation Anywhere’s Process Discovery solution can also be used to source opportunities. Process Discovery uses machine learning to identity potential processes for automation within data collected by sensors running on user desktops.
 

Assess Feasibility of Opportunities

Each automation opportunity should be assessed in terms of the costs and benefits of the automation. Many factors feed into the cost benefit analysis and the weighting that is applied to each factor can change for each organisation or even each process. It is therefore up to each organisation to determine their own approach to assessing feasibility. Some of the factors that are inputs to the cost benefit analysis are listed below.
 

The CoE Manager form used to collect automation ideas can be configured to reflect the organisation’s goals and own assessment criteria. It can therefore provide an automatic assessment of the costs, benefits, and feasibility of each idea. This initial assessment can be edited and enhanced by the Automation CoE team, and chosen ideas are then progressed to the Opportunity stage.

Process Discovery maps out the process steps, so you can see what the current process looks like, how many steps and systems are involved, and how many potential paths for the process exist. This helps you quantify many of the above factors.
 

Track Pipeline of Opportunities

Once a pipeline of automation opportunities has been identified, these must be tracked in some way. There are many ways to track this information and the systems used may change over time as the automation CoE matures. The information recorded for each opportunity should be standardised in some way to enable opportunities to be compared to each other. Information collected will include things like the following:

• A short name to reference the process / opportunity
• The process owner / subject matter expert (often who submitted the opportunity)
• A description of the process and business context
• A basic outline of the steps involved in completing the process
• Information that helps determine the costs vs benefits (see above)

As outlined above, the CoE Manager solution collects information in a standardised form and tracks automation opportunities in the ‘Opportunity’ tab of the application
 

Document the Process and Plan

This activity involves preparing documentation that will enable a bot creator to build the automation. Process diagrams are usually created, and the logic needed for various decision points needs to be defined. Screen shots and details of any APIs involved are also very useful. These documents can be attached to the opportunity records in the CoE Manager application. If Process Discovery was used to identify the opportunity, then it will produce detailed process documentation outlining the steps involved.

At this stage it may even be possible to identify any existing automation logic that can be re-used as part of the bot development process. (Building a set of re-usable components as child bots should be a focus throughout the bot development lifecycle).

Stage 2: Developing and testing

In this stage the automation is built and tested by bot creators and bot testers. In some organisations these two roles may be filled by the same person. However, it does help to separate the two roles so that testing is conducted without any pre-conceived ideas about how
the automation should be used. Development and testing should be performed against non-production versions of business systems and a non-production Control Room should ideally be used.

These activities are summarised in the diagram below and are discussed in more detail in the following sections.
 

Review and Enhance Documentation and Bot Design

It is important to re-evaluate any information about the process before beginning development work. Information that was used to build the cost benefit analysis may have changed so it is important to validate that information is still correct. The initial documentation may not be enough to build the automation so it may need to be enhanced. The bot creator will most likely need to consult the process Subject Matter Expert (SME) as part of this activity.

Develop and Unit Test

Development of all automations should be guided by standards and best practices defined by the Automation CoE. The automated code checking functionality within the platform can be used to guide and enforce best practice bot design. As part of the development process the bot creator may create or update the process solution documentation.

Ideally, templates for creating various types of bots should be created by the automation CoE. Templates can guide bot developers on best practice and should include standardised elements and structures. This ensures consistency in bot design and makes it easy for any developer to edit bot logic, which reduces automation maintenance costs.

There should be a focus on creating re-usable child bots throughout the development process. Existing re-usable components should be leveraged wherever possible. This will make new automation projects easier and will further reduce maintenance of automation logic. Templates and re-usable components should be saved to a shareable content folder in the control room so other bot creators can find them.

The owners of the process will need to monitor the automation in the maintenance stage, while the CoE will need to report on benefits delivered and other metrics. It is therefore important to build the required reporting mechanisms into the bot logic at this stage. A deeper discussion of automation reporting best practices is available here.

To facilitate easy migration of the automation between control rooms, the bot creator should use global variables or credential vault entries for any values that will change between environments. For each control room involved in the automation lifecycle the relevant parameters and credentials will need to be configured. The names of the parameters and credentials must be consistent across control rooms, but the values will change to point at different versions of business systems for example.

As a rule, each bot should only interact with a single business application. You can create additional child bots where multiple applications need to be automated for one process. This allows bots to be stored in application specific subfolders as outlined in the Best Practice Control Room document.
 

Conduct Formal Testing

Formal testing should replicate as much as possible the production environment in which the automation will be executed. It is therefore important to test against bot runner computers to identify any files, folders or software that will be required on those machines. Test data and test cases need to be provided to facilitate testing. Process SMEs should be consulted when preparing test data and test cases.

Not all automations will need the same level of testing. Mission critical automations and those which write or update data in core business systems will need more detailed testing. Also consider whether provisions for ongoing automated testing of the bot logic will be required. Logic can be added to make the bot self testing, with an input variable indicating whether the bot should run in Test or Prod mode.

The Automation 360 control room provides full version tracking. Each time the automation switches between development and testing activities the version comments should be recorded in the system. The automated code analysis capabilities in the control room can also be used to ensure that the automation meets organisational standards
 

Stage 3: Deployment

Deployment to production should be the responsibility of an admin user from the CoE. This ensures a clear stage-gate exists, where automation logic is reviewed to ensure CoE standards have been met. The bot creator should supply any required instructions for deployment, such as new global variables or credentials that need to be configured on the control room. If the bot logic does not meet CoE standards, then the automation may need to be pushed back to the Development and Testing stage. In that case there should be clear communication to the bot creator to enable them to resolve the issues.

These activities are summarised in the diagram below and are discussed in more detail in the following sections.
 

Review Logic and Structure

In this activity the automation CoE will review the bot logic and any documentation to ensure it satisfies all required standards. The automated code review within the Automation 360 control room can be used to perform checks of certain code standards, but a manual review is required for other aspects. Some of the items to be validated may include:

• Are there any extra re-usable components that can be created from the automation logic?
• Have re-usable components been created according to CoE standards and stored in the correct folders?
• Have the necessary reporting mechanisms been put in place to support maintenance of the automation and the various reporting needs?
• Has effective error trapping and reporting been implemented?
• Is the bot logic structured well and commented enough for a third party to understand it?

It may be useful to have a bot creator licence available on the Production control room. This allows the bot to be imported to a private folder while the review is undertaken. Otherwise, the automation can only be imported to the public folder where it is not editable and will be visible to consumers of automation. If no bot creator licence is available on the Production control room it is therefore best to conduct the review on the Test control room before migrating the logic to Production.
 

Check In to Public Folder

Once the review is complete the automation can be moved to the public folder on the production control room. Version comments should be set and if integration with Git has been configured this will trigger a git commit of a new version. If the automation is to run on a schedule, then a schedule must be created where a bot runner or device pool will need to be selected. Any associated Bot Insights reporting dashboards also need to be published.

If using CoE Manager, the automation record should be moved to the Deployed stage. Any configuration necessary for performance tracking of the automation in CoE Manager (or any other tool) should be completed. 

Business Handover

The automation CoE is not responsible for a process simply because it has been automated. The business typically remains responsible for the process and for monitoring the automation via the relevant reporting dashboard. A clear handover process must therefore occur, where the business owners are made aware of their responsibilities in terms of managing the automated process and in bringing any issues to the notice of the automation CoE.

Copy Across Control Rooms

If any content was changed in the deployment step, then the changes need to need to be copied to the Dev (and Test) control room(s). If the automation CoE has a Sandbox control room used for pre-release testing against cloud updates, then the new bot logic needs to be copied to that control room and any framework for testing may need to be updated.
 

Update Process Register

For ongoing operations of the automation CoE you will need to track certain metadata associated with each automated process. For example, if one of the organisation’s business systems was to be upgraded then it would be important to know which automations interacted with that system and might therefore be impacted. Important metadata about each automated process should therefore be recorded in a process register of some sort. 

Information in the Process Register would typically be comprised of the following:

• A short name to reference the process / opportunity
• The department and business owner(s) responsible for the process
• The dashboard used to monitor the process
• The bots in the control room that were created to automate the process
• Business criticality of the automation
• Links to the completed process documentation
• The software applications automated by each bot

Stage 4: Maintenance
 

In this stage the automation is monitored to ensure it is running smoothly and is delivering the expected benefits and outcomes. Well-designed reporting implemented in the earlier stages will enable the automation to be monitored effectively.

These activities are summarised in the diagram below and are discussed in more detail in the following sections.
 

Communicate to Organisation, Celebrate Successes

Automation should be promoted as a positive force within the organisation to help drive continued enthusiasm and participation in the program. A large part of this is communicating the successes and the benefits derived from the automation program. These should not be framed simply in terms of FTE reductions, but in terms of the broader benefits, which can include job enrichment by the elimination of tedious and boring work.

The CoE Manager solution provides a dashboard which displays the benefits delivered by all deployed automations. This dashboard can be instrumental in promoting automation successes and justifying further investment in automation opportunities.

Ongoing Monitoring and Support

The automation CoE needs to provide general support of the automation and the digital workers running the automations. The process owners are responsible for monitoring the number and type of exceptions, reprocessing any data, and identifying when the automation scope may need to expand to accommodate exceptions. (Exceptions should be tracked using the reporting mechanisms built into the bot). Ongoing monitoring may trigger
another iteration of the lifecycle to broaden the scope or improve operation of the automation.

Ongoing Testing of Bots With New Releases 

Cloud hosted control rooms are automatically upgraded by Automation Anywhere. Customers will be notified well in advance of when the upgrades will be rolled out. These version upgrades are rolled out to Sandbox control rooms several weeks earlier to enable organisations to test automations on the new version.

Upgrades typically have no impact on your existing automations,. But it is highly recommended to test any mission critical automations on the Sandbox environment in preparation for the upgrade just in case. A testing framework is available for automations which can automatically test bots using pre-defined inputs and comparing outputs to expected outputs. (Contact Automation Anywhere for this framework).