In part one of our four-part series, we described the Analysis and Ideation<\/a> phase of robotic process automation (RPA) intake, which includes starting small with one department and creating a process intake methodology. And in part two\u2019s overview, we review Feasibility and Priority<\/a> and the importance of establishing a scoring template when evaluating which potential processes you could automate.<\/p>\n 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.<\/p>\n 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.<\/strong><\/p>\n Below, you\u2019ll learn how to engage with subject matter experts (SMEs), the type of questions you\u2019ll need to ask during the discovery phase, and how to create a process definition document (PDD).<\/p>\n At this point, you will want to engage the business process\u2019s 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 \u2014 whether those outcomes follow the \u201chappy path\u201d or they\u2019re exceptions.<\/p>\n 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.<\/p>\n I highly recommend you record the discussion and screen-share during any business process<\/a> discovery session with the SME.<\/strong> Of course, you will want to receive your user\u2019s 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.<\/p>\n 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.<\/p>\n 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<\/a> tool that can effectively handle the majority of scenarios.<\/p>\n 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 \u2014 creating the PDD.<\/p>\n 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.<\/p>\n 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\u2019s 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.<\/strong><\/p>\n 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.<\/p>\n 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.<\/strong><\/p>\n Sample Content Categories for a PDD<\/p><\/div>\n In addition to creating the necessary automation process documentation, you should also have:<\/p>\n Also, include any other components necessary for the successful development and testing of the process automation.<\/p>\n During the discover and document phase of your RPA use case journey, you\u2019ll be able to explore alternatives \u2014 including process improvement<\/a>, native application enhancement or other automations \u2014 to make sure RPA is the right solution.<\/p>\n 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<\/a>.<\/p>\nEngaging SMEs in Your Automated Business Process Discovery<\/h2>\n
Developing Your Process Definition Document<\/h2>\n
![\"RPA](\"https:\/\/centricconsulting.com\/wp-content\/uploads\/2020\/08\/Blog_RPAIntake_07_30_20-1024x302.png\")
<\/a>\n
Bonus Moves During Process Documentation<\/h2>\n
Conclusion<\/h2>\n