Defining the process ready for solution design 

The Define phase will examine the AS IS manual process to enable the creation of a TO BE solution design

In addition to allowing all risks to be identified, a thorough analysis will expose the scope of the complete process, resulting in a comprehensive design and more economic build phase.

Process Analysis

The Process Analyst, working with the business Subject Matter Expert (SME), will provide a detailed process map and description in the form of the Process Definition Document (PDD). This will define the entire scope of the process and the granularity will need to be such for the process to be followed by a particularly unskilled user, i.e. a digital worker.

PDD Walk-through

An inadequate process definition raises the risk that the automated solution will either not work as expected or create an unsatisfactory level of exceptions. To mitigate this problem, a manual walk-through of the process as prescribed in the PDD is conducted in order to validate the accuracy and detail of the definition. The process must be followed exactly and a sufficient number of cases must be processed to provide a rough estimate of what level of exceptions can be expected when the process is automated. It is imperative that cases processed during the walk-through are a random yet representative sample, and the Process Analyst and SME will agree the walk-through volume.

A PDD walk-through is an effective yet inexpensive method of finding errors, eliminating ambiguity and reaching consensus. Correcting such problems during delivery or worse, after implementation is far more costly.

MI Requirement Analysis

Automation presents an opportunity to harvest data for the purposes of MI, usually with minimal additional development effort. MI requirements can and should be determined at the Define stage, but the Process Analyst must take care to avoid designing a solution, and instead merely collect the client's requirements in order to inform the design.

Functional Requirement Questionnaire 

The operational requirements of the current manual process and those of the future automated process will influence the solution design and should be documented during the Define phase. The Functional Requirement Questionnaire (FRQ) captures details such as the metrics, the controls, the execution and the data management requirements of the current operational process, as well as requirements for the future automated version. These details can be of vital importance when determining the scope of a solution design.

As with the PDD walk-through, asking basic questions such as 'during what hours does the process run?', 'is there a seasonal variation in workload?' or 'can the input data contain duplicates?' can have a radical effect on aspects of delivery such as estimation, digital worker resourcing or solution complexity, and uncovering such details later can come at significant cost.

What are the key input and output documents for the Define phase?

  • Business Case
  • Initial Process Assessment (IPA)
  • Business Case - Reviewed
  • Initial Process Assessment (IPA) - Reviewed
  • Process Definition Document (PDD) - Approved
  • Functional Requirement Questionnaire (FRQ) - Approved
Blue Prism Help

Visit Blue Prism Help online to find more information on the latest product features, troubleshooting advice and 'how to' guides.