Designing and documenting the solution

Solution Design Document

The Solution Design Document (SDD) is used to propose an automated solution, in order for the client to understand the design and agree that it will meet their requirements. Where definition of the AS IS process is the main entry criteria for design phase, sign-off of the TO BE design in the SDD is the 'green light' for development to commence. And like the PDD, conducting a document walkthrough with the client is an excellent way of validating and agreeing on the quality and accuracy of the SDD.

An SDD will complement the PDD and describe the construction and function of the automated process. The SDD is a comprehensive document containing not only high-level description of the automation, but also details of other components (such as input files, web services, database tables, web forms etc) that the solution depends on, together with information on security, scheduling, alerting, MI and exception handling requirements.

Discover more about Solution Design here and a template at the bottom of this page.

If you wish to enhance the capability of your solution using Machine Learning, please read our Introduction to Machine Learning as a Service

Operational Impact Document

This document describes the effect the automation will have on the Business and what the operational requirements will be after implementation. With this document, the project delivery team can ensure that the required operational architecture is in place when the solution goes into Production. And by signing off this document, the Business will acknowledge and agree to the (human) resourcing requirements necessary to support the BAU running of the automated solution. A template is available at the bottom of this page.

Process Design Instruction

A PDI is used to instruct the developers on how to build the solution that the designer has agreed with the client. As such the PDI provides the low-level detail the developers need but the client does not, in contrast to the relatively high-level detail in the SDD. As well as describing the automated process, the PDI should also cover the objects, work queues, environment variables and credentials etc used in the solution. Although the PDI is likely to be a dynamic document, its accuracy is essential for developers to collaborate in producing a solution that will meet the client's requirements. A template is available at the bottom of this page.

Object Design Instructions

As a PDI describes process construction, an ODI is used to define the business objects developers are required to build, describing the purpose, inputs, outputs etc of every page in each object. An ODI is especially useful as a 'contract' between the developer working on the process and those building the objects, so that the elements they create will fit together into the solution the designer as specified. In particular, an ODI enables a delivery manager to draft in developers temporarily to build objects, without them needing a full understanding of the solution design. A template is available at the bottom of this page.

Design Authority

A Design Authority (DA) is an essential feature of the Blue Prism delivery methodology. The purpose of a DA is to guide the delivery team, advising on how a solution design should consider aspects such as security, risk and test approach. And ideally the DA is involved right across the delivery cycle, ensuring standards evolve as the team matures. Initially the role could be performed by an individual expert but as the Centre of Excellence matures, the DA responsibility should be shared by a group of RPA practitioners.

Discover more about the Design Authority here.

Object Library

Reusing business objects is a key aspect of the Blue Prism delivery methodology that is proven to decrease delivery time and improve quality. As such it is recommended that objects are documented in a central repository that the Design Authority, solution designers and lead developers can refer to when planning the delivery of automated solutions. The repository needn't be complex and can be as simple as a list in a document.

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

  • Process Definition Document (PDD)
  • Functional Requirement Questionnaire (FRQ) 
  • Functional Requirement Questionnaire (FRQ)
  • Business Object Library (BOL)
  • Solution Design Document (SDD) - Approved
  • Operational Impact Document (OID) - Approved
  • Object Design Instructions (ODI) - Approved
  • Process Design Instructions (PDI) - Approved
  • Operational Impact Document (OID) - Approved
  • Business Object Library (BOL) - Updated
  • Design Control Checklist (DCC)
  • Testing Approach - Approved
  • Test Acceptance Criteria - Approved
  • Configuration Test Plan - Created
  • Validation Test Plan - Created 
  • Verification Test Plan - Created
  • User Acceptance Test Plan - Created 
  • Delivery plan - Created
Blue Prism Help

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