In part three of this series, we discuss the importance of process discovery and documentation during a robotic process automation use case intake and how to create a detailed process definition document.
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 in Your Automated Business Process Discovery
At this point, you will want to engage the business process’s SME(s). This is the individual, or individuals, who are considered the most knowledgeable in the execution of the process, including the requirements needed to execute and the possible outcomes — whether those outcomes follow the “happy path” or they’re exceptions.
Depending on the complexity of the business process in documentation, 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-share during any business process discovery session with the SME. Of course, you will want to receive your user’s approval to record the discovery 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 sessions, ask probing business process discovery questions as the SME walks you through their procedure. 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 a robotic process automation tool that can effectively handle the majority of scenarios.
Once you are comfortable that you have received the detail required to create a process requirements document, you are ready to move to the next step — creating the PDD.
Developing Your Process Definition Document
The PDD is an effective way to document what you learned during the business process 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 business 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.
Sample Content Categories for a PDD
In addition to creating the necessary automation 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.
Bonus Moves During Process Documentation
During the discover and document phase of your RPA use case journey, you’ll be able to explore alternatives — including process improvement, native application enhancement or other automations — to make sure RPA is the right solution.
Once this phase is complete, you can focus on tasks rather than end-to-end business processes and limit process change or improvement to reduce automation scope. Then, you can move on to the final phase: Design and Approval.
Conclusion
Follow us as we take the final step in our RPA 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 automation intake 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.