Automation Business
Analysis Fundamentals
Process Analysis
Learning Objectives
• Analyze the As-Is process.
• Define and finalize the To-Be process.
Process Analysis
Business Analyst and Solution Architect:
• Analyze the chosen process in its As-Is state.
• Start the Process Definition Document (PDD)
creation.
Solution
Architect
PDD
Business
Analyst
Process Analysis
Business Analyst and Solution Architect:
• Analyze the chosen process in its As-Is state.
• Start the Process Definition Document (PDD)
creation.
Solution • Identify the degree of automation.
Architect
PDD
Business
Analyst
Process Analysis
Business Analyst and Solution Architect:
• Analyze the chosen process in its As-Is state.
• Start the Process Definition Document (PDD)
creation.
Solution • Identify the degree of automation.
Architect
• Streamline the business flow to the To-Be process.
Business
Analyst
Process Analysis
Business Analyst and Solution Architect:
• Analyze the chosen process in its As-Is state.
• Start the Process Definition Document (PDD)
creation.
Solution • Identify the degree of automation.
Architect
• Streamline the business flow to the To-Be process.
PDD
• Populate the PDD with the As-Is and the To-
Be processes.
The PDD is one of the most critical business analysis deliverables,
Business because it ensures the transfer of knowledge from the user group to
Analyst the developers.
Process Analysis
Business Analyst and Solution Architect:
• Analyze the chosen process in its As-Is state.
• Start the Process Definition Document (PDD) creation.
• Identify the degree of automation.
Solution
Architect • Streamline the business flow to the To-Be process.
PDD • Populate the PDD with the As-Is and the To-
Be processes.
• Complete and approve the PDD.
Business
Analyst
Process Analysis
Output:
• The To-Be process is defined and finalized.
• The PDD is completed and approved.
Clients UAT Plan • The UAT plan is approved.
The UAT plan is a document outlining the tests to be performed as well
Business as the logistics for how end user testing will occur after development.
Analyst
Process Analysis: Objectives
Prerequisite
• Gather all the relevant information related to each of the components of the business process: people, technology
and procedures. Standard Operating Procedures, process maps, Organizational Chart, user manuals etc .
Aim
• Gain a deep understanding of the process.
• Document and validate with the Process Owner the As-Is process flow and all relevant data for automation.
• Design the To-Be process flow.
• Ensure a proper handover of the compiled documents to the development team to build the automation solution
for that process.
The As-Is process description should provide a clear snapshot of the current state of the process before the
automation implementation.
The To-Be process description highlights the expected design or future state of the business process after
automation.
Recommended Approach
Discovery Existing
Interviews Bench marking
workshops documentation
Shadowing/
Market analysis Direct Questionnaires
observation
UiPath products for Process Discovery – Process Mining and Assisted Task Mining
Recommended Approach
• Conduct workshops or meetings with the Process Owners and the Subject Matter Experts (SMEs).
• Obtain a high-level description of the process (walk through the process).
• Understand the complexity of the process and the challenges (from Subject Matter Experts (SME) and automation
point of view).
• Capture process metrics (scope, applications involved, no of FTEs, transaction volumes, AHTs, time dependencies,
challenges, complexity, stakeholders involved and their role).
• Prepare the PDD with the help of keystroke Level documentation or process recordings.
• Mark what is in scope and out of scope for automation from the beginning and continuously validate this classification
during the documentation process.
• Log the reasons which determine whether an action can be automated or not.
Stages of Process Documentation
High-Level As-Is Level 4 To-Be Level 4 PDD, Feedback
Requirements Process Maps Include More
Review with the Review with the Process Map and Process Map and Implementation,
and Scenarios and
Gathering Process Owner Process Owner and Sign Off
Documentation Business Rules Process Description Solution Description
Requirements Gathering
Process Metrics Applications Used
• Transaction volumes • Capture all applications used in the process
• Average Handling Time (AHT) • Understand and capture the underlying technology of each
• Total FTE effort involved in the process application
• Different instances of one application – if applicable
Process Information (e.g., Mainframe)
• Open and close times, time dependencies and SLAs
• Expected increase in transaction volume “Thin” or “Thick” Client ?
• Stakeholders involved and their role
• VDI / Remote desktops – Thin Client
• Inputs and Input type (Structured/ Unstructured and
• Desktop applications – Thick Client
Standard/ Non-Standard)
• Output and Output type
Infrastructure Requirements
• Test environment availability
• UiPath hardware / software requirements
High Level Process Maps
As-Is
Check Product Open ERP & Fill Data in ERP Generate & Reply to Email &
Open Email & PO
Code Select Transaction Screen Validate SO Attach SO
Desktop
Outlook Desktop ERP ERP Outlook
ERP
2 mins 1 min 2 mins 10 mins 2 mins 4 mins
To-Be
Check Product Open ERP & Fill Data in ERP Generate & Reply to Email &
Open Email & PO
Code Select Transaction Screen Validate SO Attach SO
Desktop
Outlook Desktop ERP ERP Outlook
ERP
1 min 1 min 1 min 2 mins 1 min 2 mins
Process Step Name Manual
Applications Used
AHT Automated
As-Is L4 Process Map
Start
OUTLOOK
Open Email Send Email to
Update File End
Open the PO in the Reply to Email and Move Email To
Email Attachment NO Attach SO Processed Folder
Lookup Product
DESKTOP
Match Found?
Description
YES
NO
Product Code Open The Master Get Product Code Validate Sales
Present? Data File Order
YES
Type in the Company Add Values for
ERP
Select the Appropriate
ERP Transaction in Specific Values for Sold To, Ship To,
Open ERP/ Login Generate Sales
the New Sales Order the Order (Sales Org, PO Number,
Order
Page Division, Channel, Material Code,
etc.) Quantity
Manual Automated
To-Be L4 Process Map
NO
Open the PO in the Input
Start Open Email Structured? Process Manually
OUTLOOK Email Attachment
YES
Send Email to End
Update File
Reply to Email and Move Email To
NO Attach SO Processed Folder
Apply OCR To Lookup Product Match Found?
DESKTOP
Extract Data Description
YES
NO
Product Code Open The Master Get Product Code Validate Sales
Present? Data File Order
YES
Type in the Company Add Values for
Select the Appropriate
ERP
Specific Values for Sold To, Ship To,
Open ERP/ Login ERP Transaction in the Order (Sales Org, Generate Sales
PO Number,
the New Sales Order Division, Channel, Order
Material Code,
Page etc.) Quantity
Manual Automated
Inputs and Outputs
As-Is process Inputs To-Be process
Aim: Identify what are the inputs needed at process level Aim: For the To-Be process documentation, analyze in detail
and at granular level and the dependencies to other sub- every input and how it can be obtained and standardized
processes. where possible.
• Input Source – from which inputs are accessed (e.g., file, a • Already existing at activity level (e.g., a report that
screen, email, a scanned invoice etc.). triggers some actions).
• Input Structure – templates from which identified inputs • Specifically created for the Automation project (e.g., data
need to be captured. to be used by the robot).
• Fields containing the input – unique identifiers to capture
the required fields.
• Input Location – location from which the input file /
application can be accessed.
Outputs
Aim: Identify if the output already exists or if it needs to be generated by the robot.
• Output type: a new record in an app, a report, a file etc.
• Destination
• Structure
• Content
• Trigger
Process Documentation Methods and Tools
Keystroke Document Process Video Business Logic
Recordings Translation Table
• Process activities detailed at keystroke • Video recordings of process activities. • Either use the existing business rules
level with respective screen shots • Recommended for complex business rules table or document the business rules in a
captured. within a process. separate file.
• Capture every action performed by the • Short video recordings (activities as • The robots can use business rules directly
SME on the application layer. modules) with appropriate voiceovers are from the table.
• Screenshot tools: Assisted Task Mining/ recommended. • In case of future rule changes, the table
Microsoft Screen recorder • Index the videos and use them as will be updated directly, with low / zero
reference in the As-Is process description. impact on the code.
• Index the business rules and use them as
reference in the As-Is process description.
Out of Scope Activities
Out of Scope Activities
• Compliance requests - must remain under the human control of team members
• Activities / source apps liable to change in the next 3- 6 months (e.g., a source app release is announced)
• Templates / inputs not standardized or involving free text / poor quality scanned images
• Activities that need human input, due to the complexity and human expertise involved
• Effort to automate a specific activity exceeds the gains
Impact of Out of Scope Activities
The impact of the activities that cannot be automated has to be analyzed according to certain criteria:
• Will it change the order of the steps performed?
• Will the robot need to be restarted?
• Will the robot need to wait for that activity to be processed first?
• Does the robot need to use the output of that manual activity?
Exception Handling
Things to remember:
• Exceptions appear in a business process when something unexpected happens during the process execution
• A process documentation that describes only “the happy path” is considered incomplete, so it is important to keep track of both
business exceptions and technical exceptions
• Make sure you cover all possible scenarios when something might not go as planned
Business Exceptions Known Exceptions
• Mandatory details are missing or are incomplete / • Previously encountered
unidentifiable • A scenario is defined with clear actions / workarounds for
• Email attachment is not available each case
App / System Exceptions Unknown Exceptions
• Application stops responding • New situation never encountered before
• System login failure • Can be caused by external factors and cannot be predicted
with precision
• It must be communicated to an authorized person for
evaluation
Quick Recap
• How to analyze and document the As-Is process.
• How to define and finalize the To-Be process.
