Process Definition

Document Overview
Agenda
Introduction
Document Revision & Approvals
Objectives & System Perspective
Process Overview
Appendices & Conclusion
Business Signoff
Documentation Lifecycle
Draft UAT
Plan
Document
Create
Process Obtain
Definition Signoff
Document

Documentation
Lifecycle
Create
The SME
Modular
Interview
Maps

Create
Create High
Discovery
Level Maps
Notes
Process Definition Document Overview

What Is It?
The Process Definition Document (or most commonly referred
to as the ‘PDD’) serves as one of the final deliverables
required to be provided by the Business Analyst (the UAT
Plan Document being the other) prior to handing off to the
Solution Design team. The PDD is the culmination off all
previous required documentation: Discovery Notes, High
Level and Modular maps. In addition, it provides clarity to all
Risk/Assumptions outlined and the Scope to be handed over
to the development team. Once this document has been
completed and signed off by the business, Solution Design
can begin.
Understanding The Importance

Outlines All Identifies

Requirements Business
that need to be Process
met by the Improvement
Solution Opportunities

Final Deliverable
Provides Risk
Provided to
Mitigation
Business before
Opportunities
Solution Design
Structuring The Document
1. Document Revision
2. Approvals
3. Introduction
• What is a Process Definition Document?
• Project Summary
• System Perspective
• Assumptions
• Constraints
• Risks
• Issues
• System Change
4. Process Overview
• Process Description
• Scope
• In Scope Functionality
• Out of Scope Functionality
• Operational Constraints and Dependencies
• Process Diagram
• Process Assumption
• Process Specifications
5. Appendices
• List of Acronyms
• Glossary of Terms
• Related Documents
6. Conclusion
Agenda
Introduction
Document Revision & Approvals
Objectives & System Perspective
Process Overview
Appendices & Conclusion
Business Signoff
Document Revision

Highlights any/all changes

that are being made to the
Purpose documentation that is
reflective of the current
‘As Is’ process.

Business requirements may

change as you go through
Importanc discovery, development and
testing. Thus, by explicitly
e stating the changes being
made, we can better keep
track of features that are
being (ex)included.

• All changes made should be clear and notated in

the ‘Document Changes’ section.

Best • All changes should be signed off (validated) by the

business before moving forward with Solution

Practices •
Design/Development.
Changes may arise during Solution Design/Testing,
however the changes to process should still be
reflected in the PDD.
Approvals
Highlights all parties
involved in
Analysis/Solution Design,
Purpose along with the appropriate
business stakeholders who
will be providing their
validation.

Business requirements and

the required documentation
Importanc may change, thus the
appropriate parties who
e provide their validation should
be clearly outlined.
.

• The Business Owner usually is only present

during the Initial Kickoff and Signoff meetings,
whereas the Process Owner/Project SME should
Best be involved throughout all of
Discovery/Solution Design.
Practices • The actual signature doesn’t need to be
included in the Document but can be provided
via email.
• Some roles may be represented by the same
party (i.e. Process Owner and Project Owner
are the same person).
• Project Sponsor is normally the client’s RPA
C.O.E. Head.
Agenda
Introduction
Document Revision & Approvals
Objectives & System Perspective
Process Overview
Appendices & Conclusion
Business Signoff
Section Overview

P Explain the
Explain Project
ur Process
Background and
Definition
p Document
Identify
Business Drivers
os Purpose
e
Outlines All
System
Requirements
Project Summary - Objectives
Important Things to
Note

Explain the purpose Scope can be Objectives should be

of automating the included in this clear and concise
entire process or key summary by and depending on
activities (i.e. identifying specific the complexity of
Modules) in the populations that will
given process and be analyzed for the process; they
how it will benefit Solution Design (see should be extracted
the business. below). during the Initial
Kickoff Session or 1st
Interview.
Project Summary - Background
Important Things to
Note
The Background You should aim to The Background
section is intended make it should be high level,
to explain the understandable to just a couple of
organizational someone who knows sentences on each
background in which nothing about the
the project is taking process. There is no key element (see
place. mention of below).
automation at this
point.
Project Summary – Business Drivers
Traditionally, a business driver is classified as
any resource, process or condition that is vital to
the continued success and growth of a business.
However, for our intents and purposes, business
drivers will also focus on the benefits of
automating the given process.

Important Things to
Drivers should be
Business DriversNote
clear and concise
vary widely
and extracted
depending on the
during the Initial
industry, scope and
Kickoff meeting with
other market
the Key
dynamics.
Stakeholders.

Aside from business drivers

outlined by the business, the
automation benefits should
be outlined, as well and
their appropriate scope
included (see example).
System Perspective – Assumptions
Important Things to
An Assumption is a factor that is considered true Backend integration
Note
(i.e. Database/API etc.)
All utilized files should
for planning purposes; however, it has not been have a
should be highlighted
proven or demonstrated. For this section, you fixed/predictable
in this section with the
naming convention
are documenting any Assumptions about the respective endpoint
that can be
Required Applications and their behaviors for the name and required
accommodated by the
credentials (see
automation to be successful. Bot (see example).
example).
The ‘Trigger Event’
should be clear and
outlined if we are
deviating from the
current ‘As Is’
approach (see
example).
System Perspective – Constraints
A Constraint is any restriction that defines a
System’s limitations. Common system
constraints would be 1) availability of System
data for BOT access, 2) speed of System given
the process SLA, 3) accuracy of data retrieved
from the System. These examples are not all-
inclusive.
Important Things to
Not all processesNote Utilizing backend
integration (i.e. Database
will have clear or API) will inherently
constraints. If so, have a constraint
you can use ‘(None regarding the data
as of most recent formatting and table
structures, along with the
update)’ as a information being readily
placeholder. available.
Data accuracy is a
common constraint
when going through
the backend as the
formatting may be
different than what is
shown on the front-
end.
System Perspective – Risks
Every project has inherent risks that may cause delay or even failure of a project. In this
section, you must identify any System Risks such as System down-time and failures (crashes),
system in-flight changes, poor data quality, etc.

Not all processes will have clear risks. If so, you can use ‘(None as of most recent update)’ as
a placeholder.
System Perspective – Issues
A System Issue is defined as known
concern/matter that involves a required
Important Things to
application that does not have a defined Not all processes Note
Some issues may be
resolution. These issues will have an impact on will have clear
indicative of a
the automation solution. The intent of outlining issues. If so, you
process inefficiency,
system issues is to be proactive in can use ‘(None as of
which may be an
most recent
accommodating them and searching for opportunity for
update)’ as a
potential solutions. These type of issues will improvement.
placeholder.
usually be the responsibility of the business to
Certain system issues may also
solve (and likely uncovered during solution be classified as a system risk,
in many cases these two are
design or development. It is important to work inter-changeable and you need
closely with your developer to understand not worry about which
category it falls under. Use
these issues. your best discretion in
determining whether it should
be considered an Issue or Risk.
System Change
The System or Activity Change is intended to:
• Address any change to a required application that has potential to arise during the
project which could cause issues.
Important Things to Note
• Not all processes will have identified system or activity changes. If so, you can use
‘(None as of most recent update)’ as a template.
• The format of the table is as follows:
• System = Name of the Application being affected
• Date = Timeframe in which the change will occur
• Owner = Business contact who can be utilized for more information about the
change
• Impact = Severity of the change
• If the potential change impact is high enough, further evaluation from both the
Solution Design team and the business should occur to look for potential
workarounds.
Agenda
Introduction
Document Revision & Approvals
Objectives & System Perspective
Process Overview
Appendices & Conclusion
Business Signoff
Process Overview
P
ur Provides Process
Outlines Modules
that are to be
p Description included In/Out of
Scope
os
e
Highlights
Showcases High
Process
Level & Modular
Constraints & Maps
Dependencies

Outlines All Important Things to Note

Process Provides Process
Process
Assumptions Metrics & Scope should be
Description should
being considered Potential ROI clear and concise
be provided by
in our Analysis as to what
the SME during
Modules are to be
the Initial
accounted for by
Discovery
the Solution.
Scope
Scope is a term mostly used to describe
everything that’s involved with a specific
project, both in what it aims to achieve and
how it will get there. The Scope serves as
the ‘boundaries’ of the automation, the
Solution will only focus on the Modules in
Scope.
Important Things to
Depending on theNote System/Business
complexity of the
process, certain Exceptions that are
Modules can be to be handled by
implemented in the business should
‘phases’ to ensure be deemed Out-of-
quicker development Scope.
turnaround
Process ‘Trigger
Events’ are usually
deemed Out-of-Scope,
depending on the
complexity of the
process (see
example).
Process Constraints and Dependencies

The Process Constraints & Dependencies Important Things to

Process ConstraintsNote
section is intended to outline any
refer
operational requirements that are necessary to behaviors that restrict a Process Dependencies
for the business (and in effect the process from achieving its refer to activities that need
goal, acting as a to be performed in order for
automation) to operate. It is imperative to ‘bottleneck’. A constraint the process to be performed
outline these as the Solution Design team may also be a timeframe or successfully. This is usually
the speed in which the the Process Trigger(s).
will have to accommodate these process must be completed.
requirements in order to provide a
successful solution.
Process Diagram
The Process Diagrams highlight the overall
logical flow of the given process (i.e. High-
Level Map), as well as the flow of the
required activities (i.e. Modular Maps) and
how they correlate with the higher-level flow
objective.
Important Things to
High Level Maps
NoteHigh Level/Modular
should be included Maps should be walked
through independently
first and the (via PDF) and are
correlated Modular included here more for
Maps to follow. formality reasons.

Naming conventions
should be consistent
with both the High
Level/Modular Maps
(see example).
Process Assumptions
Process Assumptions relate ONLY to the Process Behavior that is considered to always be true for
the automation solution. This typically pertains to activities that are deemed out of scope for the BOT
but still must be performed for the process to be completed correctly.

Important Things to
NoteShould
Should be clear as
already be
outlined in the
to how they relate
Discovery Notes
to the overall
document and
process or specific
confirmed by the
Modules.
business.

Should be viewed as
‘safeguards’ that
need to be met for
the automation to
work correctly.
Process Specifications
The Process Specifications provide a
‘snapshot’ of the process by outlining
required interactions, metric data, process
scheduling and access rights. The intent of
this section is to confirm the value
proposition of automating the given process.
Important Things to
The Input should be The Processing Time
Note
reflective of what is to should consider the
be considered the use cases analyzed in
input by the bot, not Discovery, in addition
the SME, as in many to the cycle time
cases these will differ provided by the
(see example). business.

Access Rights should Scheduling/Triggers

reflect all the should reflect the ‘To
applications that are to Be’ functionality and
be required in the should correlate with
Solution. the Input.
Agenda
Introduction
Document Revision & Approvals
Objectives & System Perspective
Process Overview
Appendices & Conclusion
Business Signoff
Section Overview
The Appendices Section is intended to:
• Provide Context to Business-Specific Terminology
• Provide Context to commonly utilized Acronyms (Business and RPA)
• Provide any related documentation that was utilized by the BA to create the PDD.
Often the Developer will reference the process recordings and when numerous Acronyms are being
used, it can be confusing to keep track, thus this helps provide context.
Acronyms/Glossary
As previously mentioned, often times the Important Things to
business and the RPA team will utilize
terms/acronyms that are relevant to both their Note
Not all processes will
process and industry. However, it can be have specific Glossary of terms is
terms/acronyms. If meant to provide
difficult to discern the meaning of these terms so, you can use deeper context for
without the proper context. The intention of ‘(None as of most business-specific
these sections is to provide business context to recent update)’ as a terms (see below).
the RPA team, as well to provide RPA context to placeholder.
the business.
Related Documents
All documentation that has been Important Things to
Not all processes Discovery Notes are
utilized to create the Process will have relatedNote not a business
documentation. If deliverable; however
Definition Document should be so, you can use
they are utilized in the
creation of the PDD,
included as reference, this will ‘(None as of most thus it should be
allow for easier interpretation of recent update)’ as a included in this
placeholder. section.
the process from parties not
previously involved. Standard Operating
Procedures (SOP’s)
should be included
in this section, if
available.
Agenda
Introduction
Document Revision & Approvals
Objectives & System Perspective
Process Overview
Appendices & Conclusion
Business Signoff
Sign Off
Processes can vary in both size and complexity; thus the required documentation will vary as well. Thus,
it is important to utilize the business time as efficiently as possible. The following documents need to
validated in order to move forward with Solution Design:
• High Level/Modular Maps
• Process Definition Document
However, depending on the complexity the Business Analyst may not be able to effectively walk
through all the documentation on one phone call and adjustments may need to be made prior to the
business providing signoff.

No

Process Conduct High Conduct PDD

Maps PDD
= Level/Modular Validated Signoff Validated
Complex Yes Yes Yes
Maps Meeting Meeting
Finish
Hand Off to
Documentation
Solution Design
No No

Make Required Make Required

Changes Changes
Next Steps…
1. UAT Plan Document Overview