Miscellaneous Sections in a PDD (Article 8 of 8)

In this section, we will explore a few key elements that, while seemingly smaller, are crucial to creating a complete and comprehensive Process Definition Document (PDD) for RPA projects. These sections, though brief, are integral to ensuring that business requirements are thoroughly documented and that all stakeholders are aligned on expectations and procedures. By collating them in a concise manner, we can ensure that no critical detail is overlooked in the automation journey.

?

Details below:

?

1.??? Risk and Dependency

This section should provide a concise yet comprehensive list of the risks and dependencies associated with the RPA implementation, along with corresponding mitigation strategies. It’s essential to identify potential risks, such as scheduled system maintenance or planned changes in business processes, and develop proactive mitigation plans. For example, regular communication protocols should be established to ensure developers are promptly informed of any planned maintenance activities. Dependencies on external systems or third-party applications should also be highlighted, along with contingency plans to address potential failures or delays.

?

2.??? Re-run Consideration

A well-documented re-run procedure is vital for ensuring that the support team can efficiently manage bot failures and recover operations. This section should provide clear instructions on how to re-run the bot after a failure, detailing whether the process should be restarted from the beginning or resumed from a specific step. Below are couple of examples:

?Example 1

If there is a failure in bot processing due to technical issues, the bot should restart the processing of that particular activity from the beginning, over-writing the previously worked content. E.g., if bot fails during preparation of XYZ Report, when bot would be run manually, it should be run from the first step of the report creation. The content created before failure should be deleted.

?Example 2

(In case of a process where bot needs to run multiple times in a day) The bot should not re-run a specific run if the start time has passed. For example, if the bot could not perform a run at 2 am CST, that particular run has to be run manually and the bot should work on next run i.e., 4 am CST in this case.

?

3.??? Required Files from Business

This section should clearly list all the files that the business must provide before the bot can execute its tasks. By detailing the required file names, locations, and any necessary periodic updates, this section ensures that the business team is fully aware of the artefacts they need to maintain. This proactive approach minimises the risk of errors or delays in the automation process due to missing or outdated files.

?

4.??? Archival of Input and Output Files

The archival and deletion policies for input and output files should be explicitly documented in this section. The bot should be programmed to automatically handle the archival or deletion of these files according to the specified rules. This not only ensures compliance with data retention policies but also helps maintain system efficiency by managing storage space effectively. Proper archival procedures are critical for audit purposes and for maintaining the integrity of historical data.

?

5.??? Process Analytics - Log Report Requirement

Documenting the need for process analytics and log reports is essential for providing the business with insights into the bot’s performance. This section should outline the specific analytics requirements, including the format and frequency of reports. Collaboration with the technical team is necessary to confirm the feasibility of these reports and to ensure they are aligned with business needs. Well-designed log reports can provide valuable information on process efficiency, error rates, and areas for potential optimization.

?

6.??? Troubleshooting Guide

This section is specifically to aid efforts of the Support Team for finding a cause of bot failure. It can also be included in runbook instead of PDD. This can serve as a first list of possible reasons for the bot failure. This will be an indicative list of reasons. This section adds value on top of error message for system/business exceptions, as such exceptions can not be detected (and reported) by the bot for each and every scenario. So, a well-thought, as comprehensive as possible list should be prepared to help the Support Team.

?

a.??? Functionals Aspects

List of possible areas where there is some unexpected change on the functional front which is causing bot failure

E.g.- Absence of a file, lost access to an application, wrong nomenclature (of a file, sheets within a spreadsheet), wrong output from an upstream process

?

b.??? Technical Aspects

Similar to functional aspects here, a list of possible issues from the technical front can be enlisted with the help of dev team.

E.g. Issues with machine storage, application downtime, bot licenses, downtime of automation tool, files being corrupt, etc

?

7.??? Appendix

The appendix should include all relevant sample documents, such as report templates, spreadsheet formats, email templates, and workflow files, using generic naming conventions like <xyz MMM YYYY>. These samples serve as valuable references for both the development and support teams, ensuring consistency and clarity in the automation process. Embedding these documents within the PDD allows for easy access and ensures that all team members are aligned on the expected outputs and formats.

??

With this last piece of article, as we conclude this series, it is evident that even the smallest details play a significant role in ensuring the success of an RPA project. By thoroughly documenting risks, dependencies, re-run considerations, and other critical aspects, we can create a PDD that not only guides the development process but also supports ongoing maintenance and optimization efforts. While this series provides a solid foundation, the real value lies in applying these principles to your unique automation projects. Frankly, there are a lot of details and experiences which cannot be penned down in a small series of articles. I hope this content has equipped you with the insights and tools needed to excel in your role as an RPA Business Analyst. Best of luck in your automation journey!

?

?

Disclaimer:?The insights I am sharing are based on my experience with specific Centers of Excellence (CoEs). It's important to recognize that each CoE operates in its own unique way. Therefore, certain aspects of the Process Definition Document (PDD) discussed in this series may not align perfectly with your CoE’s practices, and some may even seem unconventional. Please use this information with that context in mind!

?