The first section in the SDD should provide an introduction to the process to be automated and a link to the PDD. Therefore it’s really important to make sure the process and key outputs from the PDD are accurately captured in the SDD. err fingers hit the keyboard - it’s important to remember that the audience for the document will be an RPA Developer or Engineer who knows Automation 360, but doesn’t know the process. It should serve as a technical guide for the developer, outlining key process steps and how they will be automated, the applications involved, and even how exceptions should be handled.įor the purpose of the Start phase of Automation Design, we’ll dive into the Automation Anywhere SDD template before exploring how and where these documents should be stored for easy retrieval and auditing.Īn RPA Solution Architect or a senior RPA Developer/Engineer is the ideal candidate for owning and writing an SDD. The SDD should be a bridge between the PDD and the automation which will be built. When the process has been approved for automation and the PDD has been signed off by the process owner & technical team, then creating the SDD is the next step in the cycle. That is, a diagrammatic representation of what the process will look like once it’s automated.
If a Process Definition Document (PDD) is the “as-is” capture of the process, then a Solution Design Document (SDD) is the “to-be”.
The word “task bot” is used to identify component parts which make up the Bot. Note: The word “Bot” is used in this article to describe the process in its automated form.
0 kommentar(er)
