Appendix
Appendix 1: RPA Opportunity – Request Form
Appendix 2: Process Map Template
Appendix 3: Opportunity Assessment – End-to-End Process Steps
Appendix 4: Feasibility Assessment
Appendix 5: Risk Assessment Checklist
Appendix 6: Opportunity Brief
Appendix 7: Governance Committee Decision Form
Appendix 8: Solution Design Document
Appendix 9: Functional Requirements
Appendix 10: Nonfunctional Requirements
Appendix 11: Deployment and Release Setup Checklist
Appendix 12: Process Design Document
Appendix 1: RPA Opportunity – Request Form
The following information describes each field on the form:
Initiative Name: This is generally the name of the process.
Sponsor: This is the person, usually an executive leader, within whose budget the organization requesting the automation resides.
Champion: This is the leader directly responsible for the process that is proposed to be automated. They will also be responsible for removing any roadblocks that may occur and allocating required resources that would be needed during the automation development, testing, and deployment phases.
How does the process currently work: The current-state process is summarized in sufficient detail that anyone reading it has a comprehensive idea of the purpose, process flow, repetitive nature of the process, and the reason it is a candidate for automation.
What is the goal?: This indicates what portion of the process, or the entire process, is proposed for automation. It briefly lists the benefits of automating the process.
Business criticality: This section describes why this process must or should be automated at this time and how it is aligned to strategic business goals. Is there a competitive need? Is there exposure to high risks? Are clients complaining about something that would be resolved with this automation? And so on. Please be aware that some requestors will consider all their processes as “business critical,” but a little discussion with them may indicate that that is not the case.
Common business drivers: Some possible examples include, but are not limited to, the following:
Reduced cycle time
Improved consistency and quality of work
Allow staff to work on higher-value activities
Expedite satisfying governmental regulations
Maintain competitive advantage
Etc.
Impacted business areas: This lists the business units that would be impacted by this automation.
Impacted systems/tools: There may be specific systems that have been purchased or developed that will be impacted; these should be listed here. Also, any tools, including Excel, Outlook, Word, etc., that are impacted are listed here.
Opportunity type: Note here if this is a one-time automation, possibly to clean up months or years of backlog, or if it will be ongoing.
Duration of the solution: If the process is expected to be phased out within a certain time frame, or if the anticipated purchase of a new tool in, for example, 3Q2X, will resolve the issues to be addressed by automation, note it here.
Desired delivery date: Indicate when the automation is optimally desired.
Estimated operational benefits: This is generally the savings in time and cost, but not every requested automation has a significant time and cost savings. Some are required to meet regulatory or competitive requirements. Some are needed to reduce the risk of human error. If the automation will result in some time and cost savings or revenue gains, this should be explained in detail here.
For example:
5 staff members spend 3 hours a week on this process
5 × 3 = 15 hours per week
15 hours per week × 52 weeks = 780 hours per year
If a process is to be automated to save time and money, an annual savings of about 1,500 labor hours, or one full-time position, may be required to justify the solution development and maintenance cost. However, this will be different in different organizations, so it is important to establish the right criteria for yours.
Form completed date: Self-explanatory.
Prepared by: Include the names of all the people, and their roles, who had input into the request form.
Appendix 2: Process Map Template
Appendix 3: Opportunity Assessment – End-to-End Process Steps
<Process Name>
Current State End-to-End Process Steps
Version: 00
21 May 2021
Contents
Step 1. [Name] _______________________________ 1
Step 2. [Name] _______________________________ 1
Step 3. [Name] _______________________________ 1
Current State End-to-End Process Step Details
Purpose:
<Briefly summarize the purpose of the process; what does it do?>
Step 1. (Name)Input | Step Input Type(s) |
Activities | • Sub-step 1 • Sub-step 2 • Sub-step 3 |
Output | • Output Type 1 • Output Type 2 • Output Type 3 • Output Type 4 |
Roles | |
Metric | |
Notes | |
Step 2. (Name)Input | Step Input Type(s) |
Activities | • Sub-step 1 • Sub-step 2 • Sub-step 3 |
Output | • Output Type 1 • Output Type 2 • Output Type 3 • Output Type 4 |
Roles | Resource or Team Name |
Metric | • Metric 1 |
Notes | Purpose of the step is to … |
Step 3.Input | Step Input Type(s) |
Activities | • Sub-step 1 • Sub-step 2 • Sub-step 3 |
Output | • Output Type 1 • Output Type 2 • Output Type 3 • Output Type 4 |
Roles | Resource or Team Name |
Metric | • Metric 1 |
Notes | Purpose of the step is to … |
END
**************************************************************************
Explanation of detail:
Step name: This coincides with the information on the process map. If the first step is “Receive Customer Request,” that will be the name you use on this template.
Input: For the first step, this will describe what triggers the process. For example, to use our case study, the first input might be “Customer notifies company of changed address or phone number.” After that, the “input” to a step is generally the “output” from the previous step.
Activities: This is a description of what is actually performed at this point in the process. For the first step, to use our case study, it might be this: “The request is received by customer service. The representative reviews the request and forwards it to the appropriate department for handling.”
Output: This indicates what happens when the work in this particular step has been completed. In our example, the output might be this: “Request forwarded to Department ABC for processing.” This will generally also be the input for the next step.
Roles: Here, you put the name of the role, not the person, who handles this particular step.
Metric: This is optional, but over time, you may find it quite useful. In our case study example, this might include “time it takes to determine the correct department to send the request.” In that case, you might put “30 seconds” or a range, such as “30 to 60 seconds.”
Notes: This field is also optional, but can be used for any additional information you feel is required for the step to be understood.
Appendix 4: Feasibility Assessment
<Name of project>| | Questions | Answers |
|---|
1 | Is the process well defined? | |
2 | Is the process stable (very few “exceptions”)? | |
3 | Can exceptions be handled manually? | |
4 | Are inputs in digital format? | |
5 | Can required data be input without human intervention? | |
6 | Are potential changes to roles and processes acceptable to management? | |
Approvals:
<Name> <Role> _______________________________ Date: ____________
<Name> <Role> _______________________________ Date: ____________
<Name> <Role> _______________________________ Date: ____________
<Name> <Role> _______________________________ Date: ____________
Details of the form:
1.
Is the process well defined? Here, you need to determine how repetitive the process is. Basically, are the exact same steps performed each time the process is run? Are the steps well-known? Are there a limited number of exceptions? This is one characteristic that makes a process a good candidate for automation.
2.
Is the process stable (very few “exceptions”)? When the process is invoked, are the steps that are taken based on clearly established rules? Are the steps the same within the process?
3.
Can exceptions be handled manually? For any process, a certain, limited number of transactions might need some additional steps. Perhaps an account number was entered incorrectly, and the account must be looked up by last name. A customer might make a special request within a more common request. Can these transactions, if within an automated process, be sent to a mailbox for manual handling? Is there a process for handling these exceptions now?
4.
Are inputs in digital format? Do the inputs currently come into the process via an electronic mailbox? Or are they calls from clients or others that must be input by the call receiver? If so, can the input created by the call receiver be input into a system that the Bot can access?
Also, are all inputs Excel files, Word documents, PDFs, etc.? How easily might they be read by a Bot?
5.
Can required data be input without human intervention? A Bot does not think; it looks for exactly what it is told to look for and handles what it finds accordingly. If inputs require human judgment, beyond a simple decision of if it can be handled by the Bot, that process is not a good candidate for automation. Tasks that require little to no judgment and have low exception rates are good candidates for RPA.
For example, an electronic mailbox may receive 300 emails per day, and 100 of them can follow a standard process. It may take a person to manually review the 300 emails and forward the 100 that can follow a standard process to the Bot. But once there, the Bot can take over.
If, however, the mailbox receives 300 emails per day, and each requires that a person read them and look up a variety of different information that may be available from a variety of different and ever-changing sources, then this process would not be a good candidate for automation.
6.
Are potential changes to roles and processes acceptable to management? One advantage of automating processes is that staff will be freed up for other responsibilities, changing their roles. Also, when the process is being investigated for automation, efficiencies may be determined that will change the process before it is automated. These and related changes must be accepted by the process owner, in order to move forward.
Appendix 5: Risk Assessment Checklist
<Name of project>
Approvals:
<Name> <Role> _______________________________ Date: ____________
<Name> <Role> _______________________________ Date: ____________
<Name> <Role> _______________________________ Date: ____________
<Name> <Role> _______________________________ Date: ____________
Details of the form:
1.
Risks: In this area, briefly and succinctly identify the risks. One that is standard for RPA initiatives is the following: “The Bot fails to function.”
2.
Type: Generally, the “risk type” is one of the following categories:
Compliance
Error
Financial
Operational
Reputational
Resource
System
Technology
Security
Complete this area to the best of your current knowledge. Remember, this is a very early stage in the project, and additional risks will be identified as more information about the business need, the technology, etc., is obtained.
3.
Is there a mitigation plan?: This could be “Yes,” “No,” or “N/A.” “Yes” means that there is a mitigation plan for this particular risk. For the standard risk mentioned earlier, this will be “Yes.”
“No” means that there is no mitigation plan for this particular risk, but one must be created.
“N/A” means that there is no mitigation plan, but the decision is made to simply accept the risk. This may include such things as accepting maintenance costs, creation of the technical debt, or accepting the fact that X% exceptions will require manual handling.
4.
Mitigation plan and responsible party: In this box, you will succinctly express what must be done about the risk. If there is a mitigation plan (“Yes” from the column titled “Is There a Mitigation Plan”), briefly describe it. For example, for the standard risk mentioned previously, the “Mitigation Plan and Responsible Party” is usually this: “Revert to manual handling until the Bot is repaired. Business owner and RPA developer.”
If there is no plan (“No” from the column titled “Is There a Mitigation Plan”), briefly describe the steps required to create one. This might include any of the following (among others): “Confer with Corporate Risk Management,” “Obtain Input from SMEs,” “Research Industry Journals.”
Also in this section, put the role (not the name) of the person responsible for handling the risk. For the standard risk, this is the RPA team lead, along with the role of the person responsible for the process.
At the bottom of the page, include your name and the names of anyone who worked on the risk assessment, the date of the completion of the document, and then the names and roles of the approvers and the date of approval (approvals are generally provided via email, to maintain a “paper” trail).
Remember that the purpose of the Opportunity Assessment is to evaluate the request or RPA candidate for suitability and value prior to investing resources for solution development. Human nature is to jump to execution mode, and it may seem that it is a faster and more productive way, but it is more effective and more efficient to have proper assessment or evaluation of RPA candidates, especially at the early stage of RPA introduction to the organization. The amount of time spent up front will decrease as RPA culture and the technology architecture environment mature. But the introduction of RPA to an organization is not the time to cut corners.
Once all documents required for the Opportunity Assessment phase are complete, you are ready to proceed to the next Governance Committee meeting.
Appendix 6: Opportunity Brief
<Name of process>
Prepared by: <Name>, <Role>, <Department or Business Area>
Current Situation: <At a high level, describe the process as it exists today. Include how long it takes and how many people work on it. Why is the request being made to automate the process? What advantages will automation bring?> | Objective: <What, exactly, do you want to automate? The entire process or only certain steps?> |
Assumptions <What do you assume regarding possible automation. This could be that the Bot will be able to access certain systems, that inputs can be digitized, etc.> | Constraints <What do you know will be a challenge to automation? This could be that inputs are not currently digitized or that significant personnel changes requiring human resources input will be required.> |
<Include the high-level process map and information about volumes, systems accessed, tools used, and roles currently required.> |
Benefits Estimation: <List the anticipated benefits. This could be reduced headcount, quicker response to customers, more efficient fulfilling of industry regulations, or any other advantage of automating the process.> | Proposed Solution <At a high level, describe what the Bot will do.> |
Appendix 7: Governance Committee Decision Form
<Name of project>Decision | Reason for the Decision | Next Steps |
|---|
<Go, “No Go,” or “Wait”> | <Why has the decision been made? If “No Go,” detail the reasons so the requestor can be advised. If “Wait,” describe what additional information is required to make a decision.> | <Describe. For “Go,” this will proceed to the next step. For “No Go”, it will be to advise the requestor. For “Wait,” it will be to obtain the required information.> |
Approvals:
<Name> <Role> __________________________ Date: August 4, 202x
<Name> <Role> __________________________ Date: August 4, 202x
<Name> <Role> __________________________ Date: August 4, 202x
<Name> <Role> __________________________ Date: August 4, 202x
Details of the form:
Decision: This is either “Go,” “No Go,” or “Wait.” “Go” indicates that the governance body has determined that moving to the next phases is beneficial. “No/Go” indicates that for any of a variety of reasons (e.g., insufficient ROI, complexity, etc.), the project will not continue. “Wait” indicates that there is some additional information required before a “Go” or “No Go” decision is made. That will be described in the next column.
Reason: This explains why the decision was made and, in the case of a “Wait” decision, what is lacking.
Next steps: For a “Go” decision, this would indicate the next phase. For a “No Go” decision, this would indicate that the requestor is to be notified and who specifically will notify them.
Appendix 8: Solution Design Document
<Name of project>
Goal of the Automation
<Summarize the goal of automating the process.>
Applications Involved
Inputs
Flow Diagram
<Include the flow diagram that was created earlier, along with information about volumes, roles, and SMEs.>
Security and Compliance
<Include items that are required for security purposes and to adhere to compliance regulations.>
Process Steps
First Sub-processStep Number | Description |
|---|
1 | |
2 | |
3 | |
4 | |
5 | |
Second Sub-processStep Number | Description |
|---|
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
X Sub-processStep Number | Description |
|---|
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
<Describe as many sub-processes as needed to convey a thorough understanding of the process.>
Success Criteria<Describe what a successful implementation will accomplish, e.g., saving 15 hours per week, increased customer satisfaction, etc.>
Scheduling<Describe when the Bot will run, e.g., hourly, daily at 10:00 a.m., weekly, etc.>
Appendix 9: Functional Requirements
1b. Goal
2.
Triggering Event
2a. Triggers
Pre-condition
Post-condition
3.
Level 2 Details
3a. Input Parameters
3b. Output Parameters
4.
Level 3 Details
4a. Main Flow Steps
4b. Alternative Flows
5.
6.
Revision History
Appendix 10: Nonfunctional Requirements
<Name of project>1.
Privacy, Data Retention, and Purge Requirements
Data | Privacy and Retention Requirements | Accessibility | Retention Period |
|---|
Database |
Technical logs | | | |
Business logs | | | |
Business process data | | | |
Other | <Specify if any other data should be stored.> | | |
File Share(s) |
Input files | <What files trigger the Bot? What happens to the file then?> | | |
Output files | <What does the Bot produce? Where are those artifacts stored?> | | |
Report files | <Does the Bot produce reports? Where are they stored?> | | |
Other | <Document any other files associated with the Bot.> | | |
Emails |
Received | <If the Bot reads emails, what happens to them after the Bot has read them?> | | |
Sent | <If the Bot sends emails, what record of them is kept? Where is it kept?> | | |
Description |
What authentication is required for each system and application used? |
What roles are attached to the authenticated user? |
3.
Disaster Recovery Objectives
3a. Disaster Recovery (DR) Designation
<Identify any system or application required should there be a disaster.>
3b. Recovery Time Objective (RTO)
<What is the allowable gap of time (e.g., 2 hours, 24 hours) between a system going down and when they resume at some other site?>
4.
Recovery Point Objective (RPO)
<What is the acceptable time for lost data? Date received prior to the last backup will be transferred to the alternate site.>
5.
Scalability (Growth and Volume)
<Document any requirements related to scalability. Also, document the expected volume that the Bot can handle, and if there is growth anticipated, note what the anticipated future volume will be.>
Revision History
Appendix 11: Deployment and Release Setup Checklist
<Name of project>
Complete this template by filling in the information described in the “Item” and “Comments” boxes.Item | Item Details | Comments | Status* |
|---|
Product (Bot) Name | | Provide the name used to refer to the solution/automation. This name will be used in inventory, reports, change requests, etc. | |
Deployment date and time if applicable, agreed upon | | As per project plan, provide the planned/preferred date for the deployment. | |
Size of automation | | It could be small, medium, or large. | |
Bot schedule | | Specify the preferred schedule (times and days of the week). The acceptable range of start times for the Bot. The approximate runtime of Bot. Are there any service-level agreements associated with the process that affect the scheduling of the automation? | |
Contacts during warranty | | During warranty, the deployment team may need to contact a software developer on the delivery team that is familiar with the code. Ensure that the developer will be available for five business days after the deployment date. | |
Statement of segregation of duties | | Delivery team will note names of software developer(s) who wrote the code. Automation services will note names of who user acceptance tested the code and who on automation services is deploying the code. To ensure segregation duties, automation services will ensure that • The software developer who wrote the code was not the same person who performed user acceptance testing. • The deployer of the code to production is not the same person who wrote the code. | |
Volume of work | | This would be per hour, day, week, etc., depending on the process you are automating. | |
Access verification | | Mention what type of access is required and if it has been verified in production environment. | |
Email addresses for communication | | Email addresses of business and technical contacts that will be contacted for any information, errors, or other reasons. | |
Disaster recovery | | Backout steps, post-implementation steps. | |
Major/minor version | | Will this be a large-scale (as described by your organization) change, or a smaller one? | |
People who will be present at deployment | | Self-explanatory. | |
COE contact | | Self-explanatory. | |
Folder structures | | List any new folders required. | |
System/application accessibility | | | |
Infrastructure capability | | | |
Risk identification and roles responsible | | | |
Deployment instructions/steps Task deploy steps • Pre-implementation steps • Implementation steps • Test the implementation steps • Backout steps • Post-implementation steps | | If applicable, provide detailed playbook for each of the five stages of the deploy. Typically, the Automation Services Deployment Manager specifies the implementation and backup steps. | |
Communication channels established | | Include a very brief description. | |
Production support model | | Are you retaining break-fix responsibilities for this automation? If yes, provide remedy support queue name and email contact for the business technical support team. If no, automation services will engage the development team as part of the D2P process to ensure a smooth transition to maintenance knowledge transfer. | |
“Status” could be “complete,” “incomplete,” or “not applicable.” For “incomplete” or “not applicable,” be sure to include a brief, explanatory comment.
Appendix 12: Process Design Document
<Name of process>1.
Description <Describe the function of the process. Why is it done? How often? And so on. This can be obtained from the Opportunity Brief.>
2.
Current process <Describe how the process works today; this can be obtained from the Opportunity Brief.>
3.
Systems the process uses <This information can be obtained from the Opportunity Brief.>:
4.
Flow chart of the process <This was created earlier.>
5.
Detailed process steps <This was also created earlier.>
6.
Exceptions <This information was identified during process mapping.>
Created by:
<Name, Role, Date>__________________________________________
<Name, Role, Date>__________________________________________
<Name, Role, Date>__________________________________________
Approved by:
<Name, Role, Date>__________________________________________
<Name, Role, Date>__________________________________________
<Name, Role, Date>__________________________________________
