In part three of this series, you’ll learn about the importance of discovery and documentation during a Robotic Process Automation use case process intake — from engaging subject matter experts to creating a detailed process definition document (PDD).
In part one of our four-part series, we described the Analysis and Ideation phase of Robotic Process Automation (RPA) intake, which includes starting small with one department and creating a process intake methodology. And in part two’s overview, we review Feasibility and Priority, and the importance of establishing a scoring template when evaluating which potential processes you could automate.
Now, we are moving into the second half of our series, where we will take those prioritized processes and dig a little deeper (Discover and Document) to get more detail in preparation for final design and eventual assignment (Design and Approval) for development.
Based on the information received during the ideation process and subsequent acceptance and prioritization, you are now ready to take a closer look at the process to more fully understand the steps involved.
Below, you’ll learn how to engage with subject matter experts (SMEs), the type of questions you’ll need to ask during the discovery phase, and how to create a process definition document (PDD).
Engaging SMEs to Plan Your Automation Process
At this point, you will want to engage the process’s SME(s). This is the individual, or individuals, who are considered the most knowledgeable in the execution of the process, including the possible outcomes — whether those outcomes follow the “happy path” or they’re exceptions.
Depending on the complexity of the process, you may need to have several discovery sessions to fully understand and document the steps in the process and the potential outcomes for each step.
I highly recommend you record the discussion and screen-sharing during any session with the SME. Of course, you will want to receive your user’s approval to record the session(s) before you begin. Most organizations will have no issue with this unless there are security concerns with sharing the information outside of the organization.
During these discovery sessions, ask probing questions as the SME walks you through the process. Make it very clear with the user that you want as much explicit detail as possible, especially when there are potential exceptions the automation would need to handle.
Keep in mind that as you develop the automation, you want your digital worker to emulate the actions of the human actor (and the responses of applications, websites, and so on) as closely as possible, so you can create an automation that can effectively handle the majority of scenarios.
Once you are comfortable that you have received the detail required to create a requirements document, you are ready to move to the next step — creating the PDD.
Process Definition Document
The PDD is an effective way to document what you learned during the discovery sessions. It puts the information into a format that is both understandable by the end-user as well as the developer, who will help to create the solution design document (SDD) as part of the last phase of the process.
In addition to the data from discovery, the users should supply you with any process documentation they have available. This will help expedite your team’s creation of the PDD as no one will need to recreate information. Unfortunately, many organizations do not have process documentation, so it is even more imperative to derive those details during discovery.
The PDD should also capture the flow of a business process you will develop within the RPA tool.
The flowchart contained within the document captures, at a high level, the business process you will automate, the target systems used within the process and any assumptions not taken into account.
Once agreed upon as the basis for the automation of the target process, the developer and architect will use the flowchart and assumptions as a platform from which they can design the automated solution.
Changes to this business process may constitute a request for change and will be subject to the agreed agility program change procedures.
In addition to creating the necessary process documentation, you should also have:
- discussions around application access credentials
- test system availability
- test data
- quality assurance testers and user validation.
Also, include any other components necessary for the successful development and testing of the process automation.
During the discover and document phase of your use case journey, you’ll be able to explore alternatives — including process improvement, native application enhancement, or other automation — to make sure RPA is the right solution.
Once this phase is complete, you can focus on tasks rather than end-to-end processes and limit process change or improvement to reduce automation scope. Then, you can move on to the final phase: Design and Approval.
Follow us as we take the final step in our use case journey, where we’ll discuss the details of the Design and Approval phase, including key deliverables that will help drive the final phase of the overall process.
During this phase, we will finalize the PDD and receive user approval to move forward, discuss potential process improvement opportunities based on the data gather during discovery, and turn over the PDD to the technical team to create the solution design document (SDD).