In the final part of this series, you’ll learn how to finalize the process definition document and get started on the solution design document, 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 Discover 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 on your team should understand by now that you’ll need to make some modifications after testing begins and as more cases are uncovered during process execution. The need for occasional modifications should never delay the start of the last phase, nor should you allow “scope creep” to inhibit the start of development. Even after the RPA 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 business 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. Prioritize accordingly.
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 some of those processes, but it is also a good time to review and enhance those processes before automating them. 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 users and obtain approval of its content. Once approved, it’s time to hand the PDD over to your technical team to create the solution design document.
Developing Your Solution Design Document
You’ll use solution design documentation to lay out 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:
- An introduction
- Solution overview
- Operational control and alerting
- Data security and credentials
- Assumptions taken into account.
Finalizing the SDD for RPA Development
Building and getting the SDD approved is an iterative process. Though things may seem clear upon the first pass of a design, there are always further clarifications and modifications that must 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 RPA project.
Most SDDs do not require you to increment the major number, but it does happen. This is usually the case when an automation project has major functional changes added to it during the design phase.
Finally, one of the most important aspects of solution design documentation is that you keep the SDD 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.
Conclusion
You now have an approved PDD and SDD, and you are ready to begin the next phase of the engagement: RPA 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 and deployment lifecycle.
Join enterprise automation experts to learn the benefits of combining complementary RPA and BPM software engines to help your organization save time and money.
