This describes how we deliver the Blue prism solutions to Production.
These are the different documents used in the process development.
• Initial Process Analysis (IPA)
• Process Definition Document (PDD)
• Functional Requirement Questionnaire (FRQ)
• Solution Design Document (SDD)
• Operational Impact Document (OID)
• Process Design Instruction (PDI)
• Object Design Instruction (ODI)
Now let’s dig deep into the Delivery model
1.Process Management:
There are many processes which are considered for implementation.But the processes must be refined based on priority and the benefit out of them if automated.Here the IPA comes into picture.
Initial Process Analysis:
An IPA is used to illustrate the information available into relevant information for analyzing the processes considered for implementation.
An IPA is created by Blue prism Analyst or Developer and Read by : Client Sponsor
This document involves the high level description of the Process Analysis and the how much of the process can be automated and the effort involved in developing the solution and a outline of the proposed solution and production environment requirements.
The IPA will also highlight where there is further information required or the information is lacking and the Key Factor Assessment will identify areas of risk and where a Refined Process Analysis is required.
2.Define:
Here comes the Process Definition Document also known as PDD.
Process Definition Document:This document mainly describes the existing manual process that is to be automated.It is mostly given by the client or the vendor whose process we are automating.It is only created by the RPA Team when the given document lacks in detail or isn’t provided at all.
Created by – Client SME and/or Blue Prism analyst
Read by – Client SME, Blue Prism analyst, Blue Prism developer
Approved by – Client SME.
Why PDD?
A robot only follows a predefined set of logical steps.Hence PDD explains the low level of detail and expands each step that is used for developer guidance.Diagrams and Screenshots of each step should be included.It is different from the general process definition document as this document is barely like step by step procedure explained to robot.
The more detailed the PDD is the greater chance of a successful delivery.Each step with the step by step navigation and with images needs to be presented.As the RPA Developer do not have prior knowledge on the applications he has to work with.Hence the minute details provided is better for the developer to start work with.
Process Walk-through:
Generally a Process walk-through is taken with the PDD and the manual process walk-through is also given.This will help us to understand any missing scope,ambiguity or incorrect flow or any missing cases or scenarios to be handled and noted down.
Basically this walk-through is conducted to reveal gaps between the process definition and PDD. And the PDD can be revised to incorporate the details.
Participants: Client SME,Blue Prism Developer,Blue Prism analyst
Functional Requirements Questionnaire:
This questionnaire contains the unattended questions in the PDD such as client ways of working and how to operate,how they follow different procedures and how their processes work which are required to be taken care of in the Process development.
Suppose your process contains sending alerts whenever application is down.It is important to know how they handle such alerts via Message,Email,call etc.The Functional Requirements Questionnaire (FRQ) provides a quick checklist of the
required details and areas for consideration.It takes different areas into consideration such as SLA,Exception forwarding,Business continuity plans,Operating hours etc.
Participants – Client SME, Blue Prism analyst.
This Questionnaire along with the PDD helps us in Solution Design.
3.Design:
In this phase the solution development and design would be started.
Here the Solution Design Document would come into picture.The purpose of this document is to describe how the automation is carried out in Blue Prism.
Created by- Blue Prism Developer
SDD is intended to convey the solution design to the business or client and make them understand how to whole process works when automated or how it is automated.It should not describe low level details of process design and object design.Rather it should explain how each step is developed and what interactions are carried out such as Excel,Database tables etc.
The client should go through the SDD and approve the solution to proceed further with the development.
Operational Impact Document(OID) : This document is required to inform the client of the changes that will be imposed upon them after the solution is implemented or is in place.
It is only required if PDD doesn’t outline the operational changes impacted after solution is implemented.
Created by- Blue Prism Analyst and Approved by- Client operation
Once the SDD and OID: have been approved the more low level design can be started off.
Solution walk-through:
This is similar as the Process walkthrough.But here the solution is explained to the client by the RPA Team so that there are no discrepancies between the understanding of one another about the proposed automated solution and its impact on the wider business.
Process Design Instruction:
Process design instruction is like a guide on how to design the specific process.Low level details not included in the SDD can be included here.
Created by – Blue Prism Developer.
PDD describes only one business process,but a PDI needs to be created for all Blue Prism
processes that are to be created and should describe in detail the Blue Prism process, involved.
Together with all the elements (components, business objects, work queues, environment locks, environment variables etc.) that support it. The logic for working each type of case and exception handling should also be mentioned.
A completed PDI will form a work task for a developer.It is also easy to understand the percentage of work completed and the complexity of solution.
Object Design Instruction:
Like PDI,but this holds the Object design information.Its like a blueprint of the objects.It details each object and each action and the input and output parameters too.
Created by – Blue Prism Developer and Approved by a Peer review.
4.Build:
This phase involves developing blue prism solutions following the Process design templates and Object design templates and following the best practice.First the objects in the ODI should be developed may be by one or multiple developers and then the Process can be worked upon.
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.
BP release file containing the objects,work queues,process,credentials should be sent to the concerned person for review from the RPA Team so that the solution is reviewed at regular intervals.
5.Test:
The initial phases of Testing is done by the Blue prism Developers while validating the code.
There are 3 phases of Testing.
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 developer work together to prove that solution conforms to the process in the PDD.
Scenarios covering all the paths are created by the tester.At this time each scenario can be checked through and with the full speed of execution.And the estimated time for each case to run can be provided with.If the PDD covers all the process correctly then this phase runs smoothly because the process complies with the test scripts prepared by the SME/tester.
New scenarios if any missed out in the PDD will be encountered at this stage.Then the process has to be modified to cover that path also and should be tested.The
development is changed and documentation updated.If the SME is satisified in this phase then the testing can move to phase 2.
Phase 2:
Performed by – Blue Prism developer, Blue Prism tester and client SME
Blue Prism running mode – Process Studio and Control Room
Blue Prism environment – Development
Target System environment – Live
Acceptance criteria – Test script
This test phase is similar to the Phase 1 except that the process interacts with the live system and not the Test system.The Test Scenarios are picked up and tested on the Live Environment in the presence of SME as we are working upon the live Environment.Most of the real time behaviors will be reflected here as the target environment is live.
There will be minor changes required to the process if any scenarios are identified.If any major gaps are identified then the test phase moves to phase 1.
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 testing.This phase involves testing in volumes whether the process will be able to handle large volumes of data,exposing to defects or negative scenarios.No changes can be made to the process at this point of time and the process should be moved to Development environment and then the changes can be applied and a new build can be deployed.
The process runs from control room.Test reports can be taken.If 100 cases are introduced what is the accuracy(how many cases are worked correctly and how many times).
Once all the acceptance criteria have been met a full test report is published to the client
operation for sign off before the process can be deployed into production.
Build and Test phase summary:
Now your solution after it passes all the test phases is scheduled and the bot is allowed to run and hence it is regularly monitored and the solution is delivered to the customer.
RPA Geeks 
Leave a comment