Commercial In ConfidenceCommercial In Confidence
blueprism.com
Blue Prism Delivery Methodology
Process Definition Phase
Creating a Process Definition Document
1
The anchor to the process solution and test analysis. Creating a clear and comprehensive PDD is critical to delivery success
Commercial In Confidence
Release
Mgr./DA to
update master
artefact/ODI
Determine – Governance, Risk, Operational Impact etc.
Phases
Design Test
Deploy
Prod BAU
Design Develop
Deploy
Prod BAU
Lead Dev to submit
design to DA
DA to update master
artefact/ODI
Risk Approval
Business to sign off
testing
Verification Test
Final ODI
Final SDD
Deployment Plan
Ops Handbook
Lead dev/DA to check
delivery against design
docs
ODI
PDI
SDD
OID
Build
Develop
Business to agreed to
test strategy
Test Plan
Config Test
Blue Prism – Define Phase
Initialize
Define
Process Pipeline
Lead Dev to review IPA
IPA
PDD
FRQ
Commercial In Confidence
Methodology - Definition
Defining a Process Correctly
The define stage will examine the process prior to a solution design and the commencement of the configuration stage.
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 configuration phase.
Process Analysis
• Work with the business
subject matter expert
(SME), to provide a
detailed process map
and description.
• This will define the
entire scope of the
process
• Granularity will need to
be sufficient to provide
enough detail for the
process to be followed
by a user during a PDD
Walkthrough.
PDD Walkthrough
• There is a risk that a
completed Blue Prism
process running as per
design will result in an
unsatisfactory level of
business exceptions.
• To mitigate the risk of
this a PDD walkthrough
is performed.
• A business SME will
perform the process
manually by following
the prescribed process in
the PDD.
MI Requirement Analysis
• During processing there
is an opportunity to
harvest data for the
purposes of MI. Building
this into the initial
solution usually requires
no additional
development effort.
Functional Requirements
• The Functional
Requirements
Questionnaire (FRQ)
captures all the metrics,
controls, execution and
data management
requirements as part of
the current operational
process today.
• These are extremely
important and useful
when designing your
automated process
Commercial In ConfidenceCommercial In Confidence
blueprism.com
Definition Phase
Capturing the process requirements
Commercial In Confidence
Process Definition Document
Process Definition Document (PDD)
The Process Definition Document (PDD) is the most
important element of the Define phase in a Blue Prism
Project.
It provides the foundation upon which important
decision are made, and upon which a Blue Prism
automation is developed.
In this session, we will be looking at the following:
- What is a Process Definition Document?
- Where to gather information from for a PDD?
- What makes a good PDD?
- Common PDD mistakes and issues
- Testing the Process Definition with a “PDD
Walkthrough”
Commercial In Confidence
Process Definition Document
What is a Process Definition Document?
The PDD is a document that details the business process that is to be automated using the Blue Prism product.
The PDD is effectively an instruction manual which must be accurate and detailed enough to train Blue Prism robots to
perform a business process unaided, without the ability to confer with colleagues or mentors for help (like a manual
trainee would be able to!)
The PDD must be:
Clear
With a good PDD the reader can quickly gain an understanding of the process
Accurate
To ensure the robots
are trained to work the process correctly
Detailed
So the robots
knows which keys and buttons to press on every screen
Explicit
Defining exactly what information is read and used at all steps in the process
Thorough
So the robots knows what to
do in different scenarios
Commercial In Confidence
Why do we need a PDD?
A PDD is needed for the following:
• To help estimate the work involved in automating a process. A PDD is used to analyse the complexity of a process, and
evaluate what interface “components” are required. A poor PDD may lead to an incorrect estimate of the development
costs.
• To enable a Blue Prism developer to build the automation. With an unclear PDD with the incorrect level of detail,
there will be an increased requirement for Subject Matter Experts (SME’s) during development. With a PDD that is
inaccurate an incorrect solution could be built, leading to prolonged testing and live roll-out phases as the process is
corrected.
• To base Verification and UAT test plans upon. The test plans that are created as part of the Blue Prism Methodology
are based upon the process requirements as set out in the PDD.
Commercial In Confidence
Where to gather information from for a PDD?
Existing Documentation
Existing process documentation is always the first place to start when creating a PDD. If existing documentation is of a high
enough quality and at a low enough level of details it may already be good enough to be used for a Blue Prism project.
Potential sources of documentation include: training manuals, procedural guides, how-to handouts.
Potential Issues with Existing Documentation:
Outdated
The business process may have changed since the document was created
Discrepancies
Is the documentation actually how staff are working the process? If not, which is correct,
the documentation or the staff?
Level of detail
Existing documentation is often not at the level of detail and clarity required for a robotic
automation project
Ease of Use
Some existing process documentation can be difficult to read and understand
Because of these potential issues, it is always good practice to sit through the process with manual staff, even if existing
documentation seem to be good quality.
Commercial In Confidence
Where to gather information from for a PDD?
Subject Matter Experts (SME’s) – Process Walkthroughs
The best place to find out about a Business Process is from the staff currently manually working that process. Simply sitting
and watching the process being performed gives you the opportunity to:
Document the process
In the low level of granularity that is required for an automated project
Take screenshots
To include in the PDD as the SME works the process
Question the process
To ensure your understanding is clear and correct.
Kind of questions
to ask the SME might include:
-
Do you always do these exact steps for every case?
-
Do you do anything different for other customer types/account types?
-
Are there any exceptions to the rule? Are there any types of cases that you don't work or
pass onto another team?
-
Is there any rare scenarios, how differently are they worked? How often do they occur?
-
Do the systems ever stop you from taking these steps? Are there any system pop ups or
error messages that sometimes occur?
Blue Prism strongly recommends sitting with multiple SME’s when documenting a process. Different people might work
the same process differently, and just using one SME raises the risk of documenting someone doing the work
incorrectly
Commercial In Confidence
Where to gather information from for a PDD?
Business Decision and Sign Off
Process Documentation should be agreed and signed off by the business owners to ensure it has been documented correctly.
• Why:
o Ensure the documented process is correct
o Different documentation sources and staff may have provided different ways of doing the process, the business
will need to decide which way is correct.
o Documenting the process often leads to a re-evaluation of the best way to do it.
• Why:
o Subject Matter Experts: confirm that their actions were documented correctly
o Business Analyst: Any internal staff with the expertise to ensure a process is correct
o Business Process Owners: Team leader and operational managers
Commercial In Confidence
What makes a good PDD?
PDD Contents and Structure
Blue Prism provide a PDD Template and an Example PDD upon which you may base your document
A PDD should be easily understood, even by someone with limited or no previous knowledge of the business process or
the applications that is uses.
Descriptions should be clear and without any possible ambiguity. Where the PDD describes entering information into a
screen or using it within a formula, the source of that information should be clear.
A PDD should not try to document the potential automated solution. It should define the “as-is” manual process that is
within the scope for automation. Documenting the future automated solution will be done in a later design phase.
The following three slides outline the needs for the business process to be documented at individual keystroke level,
and recommend the use of a flow diagrams and screenshots.
Commercial In Confidence
What makes a good PDD?
Keystroke Level Mapping
The Blue Prism product needs to be trained to perform every key press and button click that a user would do. The PDD
therefore needs to document every low level step of the process.
• If a PDD is not documented down to the key stroke level the Blue Prism developer will not know:
o How to navigate to the required screens
o Exactly what the information to enter or select, and what buttons to press
o What messages (confirmation, warning, errors, etc..) might occur.
• The side effects of not having a PDD Available with keystroke mapping may include:
o Far greater use of SME time will be required during development
o Development will take longer, with more questions needing answering and potential delays waiting responses
o More time will be required for the testing phases, to ensure any presumptions made due to a lack of PDD
detail are correct.
Commercial In Confidence
What makes a good PDD?
High Level Flow Diagrams
Flow diagrams can make a PDD easier to read and understand:
• They enable initial high level discussions and evaluation of the process
• They allow non- developer members of an automation project to gain an understanding of the process without needing
to go into the low level key strokes
• Flow diagrams join together the component parts of the business process: the system keystrokes, the rules and
decisions, the process inputs and outputs. This gives a view of the entire scope of the process.
• Flow diagrams help to ensure the entire process has been documented. If a high level flow diagram cannot be created
then there are probably some elements of the process that are unknown or missing.
Commercial In Confidence
What makes a good PDD?
Screenshots
Screenshots capturing the system screens that the process uses can greatly help to make a PDD easier to understand.
Using screenshots has the following advantages:
• They help the PDD to be understood even when the applications being automated are not available
• They can make it easier to estimate the development effort required. The number of screens and their complexity can
be easily visualized.
• Screenshots alongside keystroke mapping can reduce the need for SME knowledge during development for
clarification
• Screenshots help the author of a PDD to remember and communicate their SME process walkthrough notes
• They remove any possible ambiguity from the key stroke mapping, especially on complex screens or screens with
similarly named field
When using screenshots it is important to ensure they are ammonized, with any customer or user specific information
removed,
Commercial In Confidence
Difficulties documenting a Business Process
Sometimes it can be difficult to document a process. Reasons for this difficulty may include some of the
following:
Problem:
• The process is very large and complete, taking an extremely long time to document
Solution:
• Break up a large process into smaller processes
• Can the large process be broken down into smaller sub-processes for automation? Breaking up a process for
automation often makes it easier to document, developer and test.
Commercial In Confidence
Difficulties documenting a Business Process
Sometimes it can be difficult to document a process. Reasons for this difficulty may include some of the
following:
Problem:
• You are constantly finding out about new scenarios every time you watch the process being manually performed. There
seems to be a never ending number of scenarios and it feels like you are documenting a moving target?
Solution:
• Use the 80/20 Rule
• It is often found the majority of cases to be worked in a business process (approximately 80%) fit into the
minority of scenarios to work (approximately 20%)
• Scoping an automation project to automate the most common scenarios will make a complete process far
easier to document, developer and test.
• Make it clear in your PDD how to identify the scenarios that are within scope for automation.
Commercial In Confidence
Difficulties documenting a Business Process
Sometimes it can be difficult to document a process. Reasons for this difficulty may include some of the
following:
Problem:
• The SME is finding it difficult to describe the reasoning behind some of their actions and/or I am finding it difficult to
define the rules being used.
Solution:
• Use Assisted Automation where subjective decisions are required
• Sometimes parts of a business process needs to be done by a person. In such circumstances the automated
solution can be built with hand offs to and from manual staff that will continue to make the subjective decisions
• Make it clear within your PDD where a subjective decision is required.
Commercial In Confidence
Common PDD Mistakes and Issues
Below are some common PDD mistakes:
• Generalized, high level Instructions. Where one line in a PDD may actually signify multiple steps.
• Vague references to other documents or lookups. Make sure it is clear where referenced documented are found, their
format, the version to use and who owns them
• Vague or unclear instructions that could be interpreted in multiple ways
• Instructions that include solutioning the automation rather than simply documenting the current “as-is” manual
process
• Missing process steps because of a presumption of knowledge, For example; how to start and log into an application
and exactly how to navigate to specific screens
• Only documenting the most common routes through the process often called the “happy paths”. Less common
scenarios and problem or “exceptions” cases are often excluded.
Commercial In Confidence
Testing the Process Definition with a “PDD Walkthrough”
The PDD Walkthrough
A PDD Walkthrough is a method of testing the PDD is correct and includes all the steps required to be able to work the
business process.
To perform a PDD Walkthrough sit with an SME and do the following; use the PDD as the guide, instructing the SME on
how to work the business process by reading from the PDD
• A PDD Walkthrough will help you to identify the following:
o Any sections of the PDD that are difficult to understand or vague. It may take an extended conversation with
the SME to understand what the PDD is instructing
o Incorrect or unconfirmed procedures. Where the PDD says to do one thing but the SME does something else.
This will need confirming by the Business Process Owner as to which is correct
o Missing steps, where the PDD says to do something and the SME does multiple actions instead
Commercial In Confidence
Testing the Process Definition with a “PDD Walkthrough”
The PDD Walkthrough
A PDD Walkthrough is a method of testing the PDD is correct and includes all the steps required to be able to work the
business process.
To perform a PDD Walkthrough sit with an SME and do the following; use the PDD as the guide, instructing the SME on
how to work the business process by reading from the PDD
• A PDD Walkthrough might be performed by any of the following:
o Anyone who creates a PDD, to ensure the PDD is correct
o Anyone assessing a process for automation, evaluating the quality of the PDD as part of an opportunity
assessment
o Blue Prism developers, to bring the PDD to life and ensure it is adequate for them to use for development
Commercial In Confidence
Process Definition Document
Recap
The Process Definition Document (PDD) captures the
flow of a business process to be developed within
Blue Prism.
The flowchart contained within the document
captures, at a high level, the business process to be
automated, the target systems used within the
process and any assumptions that have been taken
into account.
Once agreed as the basis for the automation of the target process, the flowchart and assumptions will be used as a
platform from which the automated solution will be designed.
Changes to this business process may constitute a request for change and will be subject to the agreed agility program
change procedures.
Commercial In Confidence
Process Definition Document
Summary
✓ Gather process information from documentation, watching staff perform the work, and from the business process
owners
✓ A PDD needs to contain a higher level of clarity and go to a lower level of key stroke detail than is often contained in
process documentation
✓ Problems during a process may indicate that the scope of the Robotic Automation needs re-evaluating
✓ Test the usability and accuracy of process documentation by performing a PDD Walkthrough
Commercial In ConfidenceCommercial In Confidence
blueprism.com
Definition Phase
Understanding the functional requirements
Commercial In Confidence
Functional Requirements Questionnaire (FRQ)
Introduction
The Functional Requirements Questionnaire (FRQ) captures all the
metrics, controls, execution and data management requirements as
part of the current operational process today.
These are extremely important and useful when designing your
automated process, i.e.
• Does your process need to be scheduled at applicable hours
when the applications are available?
• Does the process require an “input trigger” to start?
• Is it best to create separate “automated” processes to utilise the
robots and share the workload?
The FRQ captures the operational requirements of how the process
is manually operated today and will help design how the process
can be automated.
Commercial In Confidence
Functional Requirements Questionnaire (FRQ)
What is a Functional Requirements Questionnaire (FRQ)?
The FRQ is a document that details production information about the process and environment which may be relevant
during development.
It should capture all inputs, outputs, environmental factors, schedules, SLAs, alert structures, reporting targets, and any
other requirements of the business process in sufficient detail to be able to ensure that all requirements at all levels are
met.
The FRQ does not repeat any of the business process logic that is captured in the Process Definition Document (PDD), it
supplements that PDD document with details of the business expectations of how the process needs to perform and be
managed.
Commercial In Confidence
Functional Requirements Questionnaire (FRQ)
An FRQ is needed for the following reasons:
• To record all technical details on all aspects of the system, especially interaction points with other systems. It acts as a
reference for all development. This makes it possible to integrate with other systems and processes at all interaction
points.
• To enable developers to complete development with minimal effort. Without a properly defined FRQ before
development starts, both development and testing can be extended greatly before the process performs accurately and
meets all expectations
• To base verification and UAT plans upon. Test plans must ensure each documented requirement is met as specified as
part of the full testing process.
• To base operational planning and scheduling of the automated solution. Details from the FRQ document can be used to
decide the number of resources required, how to plan for peak work times, and when to schedule the solution to run.
Commercial In Confidence
Where to gather information for an FRQ?
Existing Documentation
Existing functional and technical documentation must be accounted for or included in data-gathering for an FRQ.
Functional and technical requirements for the process may or may not change during the BP implementation process, but
they must all be mapped either to a requirement in the FRQ or an explanation of why they are no longer relevant.
Potential Issues with existing documentation:
• Outdated – the implementation of the original process may have changed or evolved over time, meaning the existing
documentation is no longer 100% accurate.
• Discrepancies – Documentation may reflect an expectation different than the original implementation of the process,
meaning it may not actually reflect how the process is done day-to-day.
• Level of Detail – Existing documentation may not have the full detail necessary to properly develop the Blue Prism
implementation.
• Ease of Use – Documentation may be unclear, poorly written, or difficult to understand.
Because of these potential issues, it is always best practice to review all documentation with Subject Matter Experts to
ensure discovered requirements are valid.
Commercial In Confidence
Functional Requirements Questionnaire (FRQ)
Subject Matter Experts (SME’s)
The best source of information about business processes is the staff working and maintaining the process.
• Document all assumptions, requirements, SLAs, and technical elements in as much detail as possible.
• Copy samples of input and output files, reports, log entries, and alert/error messages where possible to include in the
FRQ.
• Question the process and explore/expand as much as possible, to ensure all information is correct and relevant to the
context.
• Where possible, compare the details to the live/existing process before publishing the FRQ.
Blue Prism strongly recommends sitting with multiple SMEs when documenting a process. Different people may know
different elements about a process, and working with more than one person minimizes the chance of missing critical
information.
Commercial In Confidence
Functional Requirements Questionnaire (FRQ)
Business Decisions and Sign-Off
Process and Requirements Documentation should be agreed and signed off by the business owners to ensure it has been
completed correctly.
Why:
• Ensure the automated solution meets operational requirements
• Ensure all parties are aware of the requirements, scope, and expectations.
Who:
• Subject Matter Experts: Confirm that the results of their actions are reflected correctly in the requirements.
• Business Process Owners: The process owners need to be away of the expectations of the implementation.
• Technical Staff: The technical staff who implemented the original process and work with it day-to-day will have good
insight into how the requirements match reality.
• Business Analysts: BAs frequently documented the original requirements for the process and will have good insight into
the correctness and completeness of a FRQ.
Commercial In Confidence
What makes a good FRQ?
FRQ Contents and Structure
Blue Prism provides an FRQ template in the Methodology area of the Portal and a completed example as part of the
Lifecycle Orientation training. New FRQ documents can be based upon these.
An FRQ should be clear and easy to understand. Even though the details mostly apply to technical implementation, they
should be clear to anyone reading the document.
The document should not try to record process or solution details, these belong in other definition and design documents.
Only the inputs, outputs, SLAs, schedules, alerts, reporting targets, and other technical details that are implemented by
parts of the process should be documented in an FRQ.
Commercial In Confidence
Difficulties documenting the Functional Requirements
Sometimes it can be difficult to capture FRQ information. Reasons for this difficulty may include some of the
following:
Problem:
• Requirements differ between documentation and existing implementation, or different SMEs/staff believe requirements
should hold different values.
Solution:
• Document all cases where requirements conflict, and report these to the operational process owner. Make it clear that
implementation cannot be completed and testing cannot be properly planned until all discrepancies are addressed and
corrected.
Commercial In Confidence
Difficulties documenting the Functional Requirements
Sometimes it can be difficult to capture FRQ information. Reasons for this difficulty may include some of the
following:
Problem:
• If the business process to be automated is a new business process, existing knowledge may not exist about how it
should be performed and managed.
Solution:
• A new business process should not be scheduled to be automated until all decisions about how it is to be performed
have been finalised.
Commercial In ConfidenceCommercial In Confidence
blueprism.com
Blue Prism Portal
Blue Prism Self Learning
33
Commercial In Confidence
Blue Prism User Portal
The Blue Prism Portal facilitates access to the latest software releases, framework and methodology templates, sales
support materials and supporting technical documentation.
• The forum provides an interactive,
collaborative environment within
which Blue Prism users can share
ideas, problems, solutions and
suggestions for future product
functionality
• The Releases area contains the Blue
Prism releases (historical and
present) subject to your site profile
• Includes technical, functional and
operational descriptions of how the
product works and how it is
designed and deployed across an
organization’s technical
infrastructure using the sections
below
• Blue Prism Templates provide a
base for starting new process
solutions and process examples
provide sample solutions for a
variety of common processing
• The methodology and framework
has been designed to integrate fully
with our customer's incumbent
change management systems
thereby removing the need for
additional procedural and
governance obligations
• Includes information on product
support hours and methods for
contacting Customer Service.
• The User Group provides a platform
to support the growing number of
regular users in the Blue Prism
community
• My Account enables you to change
your password or email address
and set up Subscriptions within the
Portal
Learning
• Blue Prism Learning provides a range of educational products and services to support the key roles in a robotic automation program
• It enables Developers to quickly acquire the necessary skills and experience to deliver professional Blue Prism solutions
• Complimented by additional materials and learning pathways for analysts, project managers and process controllers. The Blue Prism
Developer Accreditation exam provides a formal recognition of a developer’s ability
Learning
Forums Product Resources Customer Services
Commercial In Confidence
®Blue Prism is a registered trademark of Blue Prism Limited
Commercial In Confidence
Further information
For further information following, please review the Blue Prism Portal
that contains a wealth of information about the Blue Prism Technology and Delivery Methodology
