Deploy

The Implementation Plan details the plan to be followed during the implementation of the project. It defines the tasks to be covered before, during and after the implementation events, including those tasks performed by the RPA Team, IT and Operational departments.

The purpose of the document is to:

• Communicate and agree on the detailed implementation approach and schedule.
• Aid planning and resourcing of the implementation events.
• Record and manage implementation dependencies. It is intended for all members of the project team and stakeholders. Please refer to the Blue Prism Implementation Plan template for details of the information captured within the plan.

On rare occasions, the production environment may cease to function as expected and an emergency change may be required. For example, a system screen may have changed without prior notice.

For emergency changes, the same controls apply as for any other process changes, the difference being the time in which the changes are done and deployed.  A Request Deployment Form can be completed and authorised for emergency changes.

Note: If an emergency change is required to a process that has different versions in the configuration/UAT/Live environments, the change may need to be done and tested in each environment. This is opposed to the usual method of changing in the configuration environment and then migrating.

Some changes to a process may not require any changes to how a process works or to any of its system interfaces. They might only be relevant to the production environment. For example, the network folder to obtain a spreadsheet or the URL to use for an intranet application may change. Such simple configuration changes are only relevant to the production environment and will therefore not be done in the Configuration or UAT environments.  A Deployment Request should still be filled in explaining the change and authorised.

A request is made to export the process and its dependent objects and work queues to the Blue Prism Production environment. On successful migration a final check is performed to ensure that all required objects, systems, and work queues can be accessed by the process.

Once a new process or a process change has passed, User Acceptance Testing, deployment into the production environment can be planned and scheduled. A Request Deployment Form should be filled in.

The following information should be completed:

Target Date: This date should take into account when the change is required in production, and any business, system, or environmental pre-requisites.

Change Detail: This should be a brief description of the change and include all processes, sub-processes, and business objects that have been modified. 

Description of Testing and Acceptance Criteria: The UAT exit report and any additional testing information should be noted.

Environment Changes Required: Any changes or new requirements in the production environment should be noted here.  If required, a separate request should be raised with IT for these changes to be done.

Resource Dependencies: Details of any new or changed systems, services, or network settings should be noted here.  If required, a separate request should be raised with IT for these changes to be done.

Authorisation: The deployment request should be signed off by those who have the authority to do so.  For example, this may be nominated representatives from the Automation Team, the Business Area, and IT.

If a process has been correctly deployed, the likelihood of any negative effects on processes already in the production environment should be negligible. However, a contingency plan should exist. This will ensure there will be minimal impact on live processes if the deployment has an unexpected effect on the production environment.

The following steps may be taken as a contingency if there is a negative impact:

• Emergency Changes: If the deployment has been unsuccessful due to a minor oversight, it may be acceptable to do an emergency change to fix the issue. 
• Reversal of deployment: If the deployment has been unsuccessful and is affecting the running of business critical processes, the changes may be reversed out of the production environment. 

Operational Contingency Document

The Operational Contingency Document is updated with details of what action should be taken and when, in the event of the processing being unable to run.

Operational Process Control Document

The Operational Process Control Document is updated with details of what actions should be taken by the operations team to successfully complete a case where a Business Referral or System Exception is generated.

Environment Description Document

An update to the Environment Description Document may be required if new systems/resources have been installed or any other change to the configuration was required to facilitate the process.

Operational Handbook

The Operational Handbook is updated to describe how a process is to be started or restarted.

BAU Support Policy

It is essential that a Service Wrapper is implemented for the live Blue Prism processes to ensure smooth day to day running of the automated processes and to prevent the processes from decaying as systems/business processes evolve. The support policy provides the guidelines on the optimum Service Wrapper for Blue Prism