Home Blue Prism BP Manish Sharma Robotic Process Automation RPA Solution Design Document Delivery Road-map/Life cycle of Blue Prism Process

Delivery Road-map/Life cycle of Blue Prism Process

Read


1. Framework


The Technical Infrastructure element provides a structured and scalable technical environment for process delivery by the corporate security policy. The Operating Model provides a repeatable, structured, and controlled model for identifying, prioritizing, delivering, and supporting process delivery, plus continually sustaining and improving the automated processes in the operational environment.
This Delivery Roadmap navigates through the following stages:
  • Process Management
  • Define
  • Design
  • Develop
  • Test

2. Process Management
Initial Process Analysis

During the Opportunity Assessment, a list of candidate processes will emerge that, following a prioritization exercise will require an initial process analysis (IPA) before they can be considered for implementation.
An IPA is a means of framing the information available at the early stage of a project into a succinct document illustrating the salient points.
The objective of the IPA is to provide a high-level analysis of the process solution, the automation efficiency (how much of the work can be performed by a robot) and the effort involved in delivering and supporting the solution. Only a high-level overview of the a business process is required, and similarly only a basic outline of the the proposed solution is necessary.
The analysis is required to consider:
  • The proposed solution
  • Process metrics
  • Pre-requisites to development
  • Delivery effort
  • Exceptions and referral rates
  • Production environment requirements
  • BAU support requirements and effort
The IPA will also highlight where existing information is lacking in detail and the Key Factor Assessment will identify areas of risk and where a Refined Process Analysis is required.

3. Define

Process Definition Document-PDD

The main purpose of a ProcessDefinition Document (PDD) is to describe the manual process that is to be automated. The PDD only needs to be created where existing process documentation does not exist or isn’t provided to the required detail.
Process Detail

A robot cannot think for itself and can only follow a set of predefined logical steps. A PDD should, therefore, go beyond the level of detail normally provided to a human and specify exactly how the process is to be carried out. A diagram and descriptions of every stage in the diagram should be included.
Existing process documentation may not be written from the perspective of a robot. It may contain subjective decisions that appear simple to the reader but such decisions a robot will have difficulty interpreting. Such ambiguities should be resolved in the PDD. The design of a Blue Prism solution will be based on the PDD, so the more explicit the PDD, the greater the chance of successful delivery.

Application Detail

Application screenshots and descriptions of each step should be provided, with annotations applied to the images where necessary. Any system warning messages, pop-up messages that might appear should also be explained.
It should not be assumed that the developer of the automated process will have any prior knowledge of the applications involved, and so the more detail regarding the behavior of the applications provided, the better.

 Process Walk-through
Once a process has been defined, the quality of the PDD can be gauged by using it as a step-by-step instruction manual. A perfect PDD would enable a novice with no prior knowledge of a business process to work cases correctly.
During the walk-through, a random sample of cases is worked by following precisely the flow and rules defined in the PDD. This will expose any missing scope, ambiguity, or incorrect flow.
Should the walkthrough reveal gaps in the process definition, the PPD can be revised with additional detail. Another walk-through may be required, depending on the scale of the changes.
Functional Requirements Questionnaire-FRQ
The PDD will capture the process steps but all the wrap-around functionality to enable the process solution to run unattended whilst meeting the demands of the business will need to be defined. The Functional Requirements Questionnaire (FRQ) provides a quick checklist of the required details and areas for consideration.
  • Workload
  • Resource Requirement
  • Service Level Agreements
  • Operating Hours
  • Alerting
  • Data Management
  • Exception forwarding
  • Management Information and other reporting
  • Data Preservation
  • Business Continuity
These functional requirements along with the PDD will feed into the solution design.

Solution Design Document

The purpose of the SolutionDesign Document (SDD) is to describe how BluePrism will automate the process described in the PDD.
  • Created by – Blue Prism developer
  • Read by – Client operations, IT
  • Approved by – Client operations, IT
The SDD is intended to convey to the Business and IT sufficient detail of the automated process for them to understand and ultimately approve the proposed solution. Critically, it should not go into low-level detail of how the Blue Prism processes and business objects will be developed, as this is likely to cloud the client’s ability to sign off the design with confidence. This detail is reserved for the Blue Prism Process Design Instruction and Object Design Instruction.
As well as describing the automated the solution, the SDD should include details of any other deliverables that are required, such as web services, database tables, input files, network folders, etc. Other derivatives such as security requirements, scheduling, alerting, management information, and exception handling procedures should also be mentioned.
The SDD includes a description of
  • Overview of an end-to-end solution
  • Object model
  • Operational control and alerting
  • Data security and credentials
  • Business and technical assumptions

4. Operational Impact Document

The Operational Impact Document (OID) is required to inform the client operation team of their responsibilities once the automated solution is in place. It is a description of the change that will be impacted upon them once the solution has been successfully implemented.
The OID is only required if the PDD does not explicitly outline the post-operational impact to the business.
  • Created by – Blue Prism analyst
  • Read by – Client operation, Blue Prism controller
  • Approved by – Client operation
There may be an effect on areas of the business downstream of the automated solution, for instance, in dealing with exception cases. Similarly, the way the business works upstream of the automated solution may need to change, for example in the way work is fed into BluePrism. The OID explains the operational, resource and IT requirements the automated solution will make of the Business.
Once the Solution Design Document and Operational Impact Document have been approved the more detail lower-level design can begin.
Workshop
In the same way that the PDD should be played out, a workshop to a walkthrough of the SDD and OID should be carried out to check the proposed automated solution and its effect on the wider business.
As with the PDD walkthrough, such role-play may reveal deficiencies in the solution that prompt a rethink and a change to the design.

5. Process Design Instruction

A Process Design Instruction (PDI) is intended to be a blueprint from which a process can be developed. The low-level information excluded from the SDD for the sake of clarity should be included in the PDI.
A completed PDI will form a work task for a developer.

6. Object Design Instruction

Like a PDI, the Object Design Instruction (ODI) is created as a blueprint from which business objects can be developed. The object design instruction describes each object to be built and each action within that object lists the input and output parameters and the start and end screens.

7. Build

Objects from the ODI should be developed first and then the processes. As there are typically multiple objects multiple developers can be involved in object development. Only one developer at a time however can work on a process.

Blue Prism process templates should be used when creating Blue Prism Processes.
During the implementation of the Blue Prism Framework, a local design authority will be agreed that will govern design control and development best practice. Peer review is essential at regular stages of the development phase to ensure development quality.
At the end of each object and process, development task unit or configuration testing is performed by the developer.

8. Test
 
As the terminology used to describe test phases can differ from client to client, this document will use generic terms in an attempt to avoid any potential misunderstanding of terms like validation, verification, live proving and UAT. The following phases form the starting point from which a local test approach is agreed during the Blue Prism Framework implementation. The agility of the Blue Prism platform allows for testing to take place during development. Only when you get to test phase 3 are developers no longer involved.
Phase 1
  • Performed by – Blue Prism developer, Blue Prism tester and client SME (optional)
  • Blue Prism running mode – Process Studio and Control Room
  • Blue Prism environment – Development
  • Target System environment – Test
  • Acceptance criteria – Test script
In this phase, the tester/SME and the developer work together to prove that the solution conforms to the captured process definition (PDD).
Scenarios are created by the tester in the test environment that validates the process along the various process paths. Starting in Blue Prism process studio cases are stepped through and as confidence in the solution increases the processing speed can be increased until eventually, the process is running at full speed. At this point, case processing time estimates can be provided.
This is the stage where the quality of the PDD comes to light. Both the SME’s test script and the developer’s work are based on the original process definition, and if that definition is accurate and comprehensive then this test phase should run smoothly.
However new scenarios not mentioned in the PDD may be encountered at this stage. If this happens, testing may need to stop while a resolution for the scenario is identified, the development is changed and documentation updated.
Once the tester is satisfied that the scripts have been passed, testing can move on to the next phase.

Phase 2
This test phase is largely a repeat of the last one, but with one significant difference. Where previously test systems were used, here the tests will be carried out with live data. The presence of an SME is mandatory to confirm processing as data is committed to the system.
Testing is largely in Process Studio and unlike the previous phase where scenarios were manufactured to enable the tester to prove the solution against the PDD, here cases are randomly selected. Test scripts will list all the different scenarios that must be proven with live data and this can be checked off as the the process works through the live cases.
Only the most basic processes captured in a PDD will be completely comprehensive. You must assume that there are unknown scenarios and system responses that will only be exposed with live data and as this test phase progresses these can be trapped, fixed, and re-tested.
This phase may evolve into a cycle of testing and fixing as the tester, SME and developer find and apply corrections to the solution. Ideally, these will be minor tweaks that can be applied safely during this test phase. However, should significant gaps in scope be identified and extensive rework be required then delivery should return temporarily to the development phase?
Once the test scripts have been proven with live data, the solution can be packaged deployed to the test environment and testing can progress to the next phase.

Phase 3
  • Performed by – Blue Prism tester, client SME
  • Blue Prism running mode – Control Room only
  • Blue Prism environment – Test
  • Target System environment – Live
  • Acceptance Criteria – Volume, performance, and quality targets
In this phase the process solution is deployed into the test environment for final acceptance testing.
This phase is largely about testing that the solution can handle an increase in volume and by putting larger volumes through the process expose any remaining defects, performance, or environmental issues. The testing to this point should have proved the solution is robust and that the need for further fixes is unlikely. No changes can be made to the solution in the test environment. All defects must be reported and fixes applied and tested in the development environment. For minor fixes phase, two can be bypassed and a new release migrated into the test environment.

The process runs only in the Blue Prism control room. During this phase, case volumes must be strictly managed and quality controlled. Multiple sub-phases may be introduced. Each sub-phase will have it's quality and acceptance criteria e.g. work 100 cases with 100% quality checking without defect. As the test phase continues to prove the quality of the solution.

Volumes can be gradually increased and quality managed by spot-checking until eventually, the final acceptance criteria are satisfied.
Once all the acceptance criteria have been met a full test report is published to the client operation for signing off before the process can be deployed into production.

Build and Test Phases Summary



Roadmap




----------------------------------------------------------------------------------------------------------------------------
Contact me if you need any RPA project development or Support
----------------------------------------------------------------------------------------------------------------------------
Contact me if you need a Responsive website/ web-application
----------------------------------------------------------------------------------------------------------------------------
Tags :
Powered by Blogger.