There are basically 7 stages in the RPA life-cycle, but in this article, we are going to address about solution design phase, its documentation, and the most widely used acronyms that appear regularly in RPA conversations: PDD (Process Design Document) & SDD (Solution Design Document). Although there are many facets to be explored, we are going to limit this article to PDD & SDD in RPA

RPA or Robotic Process Automation is currently a hot buzzword that has been able to capture the imagination of large-scale organizations, especially the ones that are preparing to transform into digital working enterprises. To put this statically, a Grandview study estimates that the Automation sector’s value is expected to soar from $358 million in 2017 to $3.11 billion in 2025. 

Moreover, many business leaders have started taking RPA seriously. In Fact, 85% of large & very large-scale organizations are planning to deploy some form of RPA by the end of 2022. Since all businesses rely on reduced cost & efficiencies, robots or software can help them automate a transaction, communicate with other digital systems, or extract & manipulate data. 

What is RPA Solution Design Phase? 

The RPA lifecycle is the structure of how automation is delivered and executed. It consists of every one of the phases a bot goes through: from identifying a business process or task to automate through to its deployment as a bot in production and its continuous monitoring thereafter.

RPA solution design in RPA lifecycle management comes after ideation & assessment. It includes modeling & defining processes or tasks that need to be automated that are discovered in the discovery phase. It also includes mapping any dependencies that the automation might have. For instance, the automated task will interact with a system or regulations that impact it. 

The design phase of the RPA lifecycle features a blueprint for RPA developers to analyze and understand what tasks need to be automated. Traditionally, the Design phase is drafted in paper-based documents like PDD, but with time this process has ushered in a better, digital way of design. The RPA development phase comes next. 

Before we proceed further, it’s essential to have a solid foundation in automation testing principles and selenium basics. If you’re eager to dive deep into software testing, consider joining GUVI’s Automation Testing with Selenium Career Program. In this program, you’ll learn the fundamentals of Selenium, Python, Java, Jenkins, JMeter, API Testing, and more. Gain hands-on experience with industry-standard tools and techniques to get into a professional career focusing on the quality of Product & Process development.

Also, if you want to explore Automation Testing with Python through a Self-paced course, try GUVI’s Self-Paced Selenium Automation with Python certification course.

Process Definition Document (PDD)

PDD is the first document in the Design phase, that is created once you have a process walkthrough with the SMEs or the process experts. It’s effectively an instruction manual, accurate and detailed enough to refer to the software design document. (SDD)

PDD is an effective way to document everything we have discovered & learned in the discovery phase. It puts the information into a format that is comprehensible by the End User as well as the developer. Basically, it outlines all the processes that require automation and can bring efficiency to the whole process. 

Documenting a process is an integral part of Software Development. In fact, all SMEs or corporations rely on neat software documentation. It’s an essential part of the RPA lifecycle. It implies gathering as much processed information as possible about the task and recognizing all the gaps and possibilities for improvement through Automation tools. (UiPath, Automation Everywhere, Blue Prism, etc) PDP includes process flow & sequence of all the steps for the ongoing manual process. It also illustrates potential plans for process automation via mind maps or diagrams. Key details regarding PDD include transaction load, risks, error handling, FTE, dependencies, and expectations ( knowns as well as unknowns) 

PDD is a highly confidential document only accessed by top-level business managers & analysts. It contains vital information, and only after final approval, they are handed over to the development team. 

Any changes to PDD may constitute a request for change, which is subject to agreed agility program change procedures. 

Important components of PDD

• Objective – It defines the objective of this document
• Introduction – Introduction of the process planning to get automation. 
• Applications in scope – Number and types of the applications in scope
• High-Level Process Steps – L1 or L2 level process steps
• Scope/Out of scope – Process in the scope of Automation & out of scope
• As-is process flow/map – Flowchart of As-is process(current process map)
• Detailed process steps – Keystroke level process steps(with print screen or screenshot)
• Exceptions – Any business or technical exception
• Any Queries – List of Queries that you may ask

Software Design Document (SDD) 

In the next stage, Top-level developers prepare a Software design document (SDD) and help end-users how to implement the automated system. SDDs are crucial for every business process that is automated using RPA and they contain High-level design reports to describe the potential planned automation. Usually, a solution system architect or tech lead creates this document and it is a blueprint for developers working to build automation. The design is open for specific integration and business management processes that developers are working on. 

It’s essential to get the sign-off of SDD from the business owners before the development starts. It defines the work ethics on how to handle errors and exceptions and at the same time passed on to the user.  It not only improves the stability of the bot but allows insights into scenarios that may have been omitted. This is critical for processes that involve a transaction, as the whole operation can get halted due to one single failure. That’s why there’s a need for a proper resilience plan to ensure minimal risk in the event of bot failure or server/software issues. 

As SDD contains a complex nature, it’s advisable to use versioning and track changes to ensure access to previous drafts. 

Basic components of SDD

Below are the key components of the Solution Design Document:

• Business and technical requirements of the PA projects
• High-level design approach
• Solution design in terms of process flow
• Data flow diagram describing the technical solution
• List of discrete services/activities that are part of the flow(keystroke level)
• Best practices guidelines describing project phases and tasks
• Exception and alternative flows
• Effort estimate for the project
• Deployment scenario for the solution in terms of hardware and software needed

Summary 

When it comes to RPA, documenting almost everything is a blessing rather than a curse. Creating PDD & SDD in RPA doesn’t necessarily imply immediate automation but ensuring access to key information & knowledge. So that it can be readily accessible to future developers & users. 

Read More: Learn 12 essential skills to become an RPA developer. 

Enroll in GUVI’s Automation Testing Career Program to get your software testing career off to a great start. Here, you can master in-demand skills like Selenium, Python, Java, Jenkins, JMeter, API Testing, and more.

Alternatively, if you want to explore Automation Testing with Python through a Self-paced course, try GUVI’s Self-Paced Selenium Automation with Python certification course.