In the final part of this series, you’ll learn how to finalize the process definition document (PDD) and get started on the solution design document (SDD) so you can move on to RPA development.
Throughout the first three parts of our series on “Choosing the Right Process for RPA,” we covered the Analysis and Ideation, Feasibility and Priority, and Design and Document phases at a high level. In the last part of our series, we will look at Design and Approval and the steps you need to take to get your robotic process automation to the development team for design, creation, testing and eventual deployment.
You have done a great job to this point of identifying the processes that are viable for automation, and now you need to get it over the finish line — and on to the start of the development race.
At this point, you need to put the finishing touches on the process definition document (PDD) started in the design and document phase, ensuring you have captured all the known steps and exceptions as shared by the users. Then, you can start on the solution design document (SDD), so you can capture the flow of the automation.
The PDD Final Touches for Successful RPA Deployment
There are a few things to keep in mind as you finalize the PDD. First, everyone should understand by now you’ll need to make some modifications after testing begins and as more cases are uncovered during process execution. This should never delay the start of the last phase, nor should you allow “scope creep” to inhibit the start of development. Even after development is done, if you have captured 80 to 90 percent of the scenarios in the process, you are in a good position to deploy and enhance once the automation is in production.
During this time, you may also need to make the process more effective and efficient. Keep in mind, you’ll still execute many processes manually, knowing you may need eventual improvement — however, time is of the essence, so you might never get the chance to address those improvement opportunities.
Many organizations do not make it a priority to review their processes on a frequent basis. So with the onset of process automation, not only is it a good time to automate processes, but it is also a good time to enhance the process before full automation — hence, “automating a bad process gets you the same bad results, only faster.”
The last piece of the puzzle is to review the PDD with the appropriate business user(s) and obtain approval on its content. Once approved, it’s time to hand it over to the technical team to create the Solution Design Document (SDD).
Solution Design Document
You’ll use the SDD to document the proposed automation solution, based on the contents of the requirements and the PDD. The SDD captures the details of the “to be automated” flow of the business process. It also captures the target systems used for the process, exception details, security details and assumptions taken into account.
Having an effective SDD is a vital piece in any RPA project. Replicating a manual process as-is is not always the way to go, as there could be a more efficient way of doing the same process when it comes to automation.
For instance, retrieving information from an application — web-based or otherwise — takes time and may require navigating through a series of screens and fields. However, from an automation perspective, you may achieve the same result by accessing the data directly (using an API or HTML versus click-through processing), thereby saving processing time and improving the effectiveness of the automation.
A good SDD should include the following information at a minimum.
Finalizing the SDD for RPA
Building and getting the SDD approved is an iterative process. Though things seem clear upon the first pass of a design, there are always clarifications and modifications that take place as people give the process more scrutiny.
You should incorporate all changes into a new version of the spec. Title the initial version of the spec draft “v1.0” with subsequent versions incrementing the sub number (e.g. v1.1, v1.2, v1.3, and so on), assuming the modifications and clarifications do not change the scope of the project.
Most SDDs do not require you to increment the major number, but it does happen. This is usually the case when a project has major functional changes added to it during the design phase.
Finally, one of the most important aspects of the SDD document is that you keep it current during the development and testing phases. It is critical any modifications made to the process — to accommodate variances uncovered downstream of the build draft — get incorporated back into the spec. Otherwise, the spec will have little use when users try to use it to understand exceptions or use it as the basis for subsequent phases of a project.
You now have an approved PDD and SDD, and you are ready to begin the next phase of the engagement: development and testing. And during this phase, you’ll also have identified opportunities for general process improvement, using RPA as a wedge to separate operational excellence projects.
It doesn’t stop there though.
You have most likely defined many processes viable for automation. To keep the “RPA Factory” moving and the developers busy, you need to document, design and approve the next process(es) — kind of a “wash, rinse, repeat” cycle. As you continue through these processes, not only are you improving the business processes themselves, but you are also continuing to review the Use Case Intake and Analysis process to make it more efficient and effective, thus improving your overall design, development, deployment lifecycle.