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.