Writing a perfect solution design or solution architect for any RPA solution is the most critical piece into the RPA development process. In this article, going to suggest some best points for writing a good Solution Design Document (SDD) for an RPA solution. Here, I shall not go deep into the Table of Contents of any good SDD or Solution Architecture Document, while good templates are already taken care of by the respective process engineering teams.
Blue Prism is a platform for creating automated processes and executing them in a secure, virtual environment. An automated process should be able to run unattended and unobserved, and this document sets out to explain how to make this principle central to solution design.
1. Designing for Unattended Automation
A Blue Prism process needs to be much more than a series of manual steps executed automatically. It needs to be robust enough to work unattended, be able to recover from unexpected situations and work concurrently on multiple machines. This realization is often missed when learning to design a Blue Prism solution.
After focusing on the definition of the manual process in the PDD, a common mistake is to envisage the automated process merely as a linear sequence of work steps.
This is too simplistic because the objective of the process is to work one case after another, and after completing one case it will need to return to the start position in readiness for the next. So the process will need to maintain control over the applications and data it is using, and these reset steps may well involve navigating back to the main menu screen and resetting variables.
At some point, the process will also need to break out of this loop, and often this is simply when there are no more cases left to work but the decision could also be made for other reasons, such as when the end of the working day is reached.
It is also likely that there will be additional steps before and after the working loop. Examples of preparation steps are things like logging in to applications and gathering input data. The finishing steps could be something like logging out and closing down the applications, creating a report or sending an email notification.
To illustrate this consider the following process constructed using the Blue Prism Basic Template. The three areas outside of case processing (work) are clearly marked.
Another common oversight when designing a process is to assume that it will never encounter any problems and always stay on the ‘happy path’. Again, this is unrealistic and recovery steps should be included to cater for the ‘unhappy path’ logic, as shown below in orange.
Here exception handing is employed to make the process recover from unexpected application behavior, so that cases can be set aside for manual investigation or if necessary, reworked by the process. The recovery logic may also need the ability to restart applications for the process to continue working.
There are different types of an automated solution that can be applied to a manual process. Consider this abstract process, comprised of manual steps 1 to 9
- Full Automation: The ideal scenario is when all manual steps can be automated and that the entire manual process can be replaced. Note that for simplicity the effort in manually resolving exception cases has not been illustrated here.
Partial Automation: If complete automation cannot be achieved, then it may be possible to automate a sequence of contiguous steps within the original manual process. Ideally, the effort in the remaining manual steps would be offset by the savings brought by the automated steps. Often in this kind of partial automation, an adjustment to the remaining manual steps is required to enable the automation. For example, in step M1 the user may need to prepare structured data for step A2 to consume. Similarly, in step M9 the user may need to become the recipient of a handoff from A8.
Fragmented Partial Automation :
If continuous automation cannot be achieved, then maybe automation can be applied to more than one sequence of steps.
Here the links between the manual and automated steps need to be considered when weighing up the overall benefits. If the handoffs require new manual effort, then that may negate the idea of automation, but if a synchronized interplay can be achieved easily, then fragmented automation may work.
Restructured Partial Automation :
- To avoid fragmentation it may also be possible to re-engineer, or re-order some of the manual steps to facilitate a continuous sequence of automation.
- Here steps 1, 4, and 5 have been arranged into a manual sequence to enable 2, 3, 6, 7, and 8 to be automated in one straight-through process.
Refer the site: UiPath tutorials
Visit my blog about RPA: Robotic Process Automation (RPA) with Blue Prism (PDF)
The delivery of a Blue Prism solution into a production environment follows a standard path of Define- Design- Build-Test-Implement, familiar to many IT projects. Blue Prism offers a proven design methodology with accompanying document templates, and trainees are introduced to these as part of the Lifecycle Orientation module. These templates are not prescriptive however, and some clients are more comfortable adapting their own methodology and documentation to work for RPA. It is the purpose of the documentation that is important, the documents themselves are merely vehicles – for defining requirements, exposing detail and for reaching an agreement.