Documentation is critical at every stage of customization. From initial requirements gathering, functional design, technical design, and user guides, each piece of documentation is a critical roadmap to guide you and your team to success.

Documentation from requirements gathering and functional design will provide important insight into why the process was designed that way, why certain decisions were made, and who was involved in the decision making process. You may think these details are immaterial once the customization is complete and tested, but there may be a point in the lifecycle of your ERP where a question about the initial requirements and design may come up. 

Technical design documentation provides a technical roadmap of what was changed and created and a point of reference to make future changes, should they be needed. 

User guides should always be created, showing the different use cases for the solution, including any prerequisite data or configuration. A step by step guide can help empower your users to embrace and own their new custom process. 

Take those user guides one step further and setup automated testing if it is available to you. RSAT (Regression suite automation tool) is a powerful tool for D365 F&O that can help minimize the time needed to regression test your customizations when performing system version updates or introducing additional customizations. Check out Microsoft's documentation here.

As an end-user, these documents are important for future needs. Guides can be used to help get new hire familiar with the custom process needed to complete their job. Providing this documentation to show your new partner what has been customized in your ERP system will save time and resources from spending countless hours trying to understand your custom process, how to use it, and why certain decisions were made.

Creating and maintaining this documentation is critical to ensure you have the full picture of where the customization began and where it has gone. I like to think of it as a gift to my future self-- something to look back on as a quick refresher of why things were designed and developed a certain way. 

Multiple stages of testing are critical to ensure your customization meets needs, can survive human error, and is free of bugs. 

Quality assurance testing (QA) is one of my favorite things to do. Design is fun, but when I am QA testing a solution, my goal is to see if I can break it (sort of like quality testing on a toy to see if it will break). While we would like to think our solutions will only be used for the intended purpose, human error is inevitable. Testing should never follow a perfect path--plan for deviations from the standard process and be sure the customization will handle those deviations, or reject them, as desired. The more issues that are identified in QA Testing, which is typically performed by partner, the smoother UAT will go, and the happier your end users will be.

User acceptance testing (UAT) should both be completed with 2 questions in mind. 

1. Does the solution meet my needs?

2. Does the solution account for human error?

User acceptance testing should consist of multiple scenarios and look for both positive and negative outcomes. Simply testing the intended design of the solution could cause problems in your production environment when the use case changes slightly. UAT is your last chance to find issues before it could impact your production environment.

Regression testing should be completed each time a change is made to your ERP, from additional customizations to version updates. Regression testing is designed to ensure none of the changes in your system will negatively affect another customization. Regression testing can help prevent issues and downtime in your production environment. Taking the time to properly regression test can save you and your company time, revenue, and a very large headache if there is a negative impact from additional changes to your system. Testing for issues before the changes hit production are key. 

As time passes from the initial implementation of a customization, there may be a need for continuous improvements and proactive changes. Changes may result from many situations, such as regulatory requirements, business process changes, introduction of additional software, additional integrations, and version upgrades.

As knowledge of these types of changes come up, review customizations to determine if there is a need to make continuous improvements or proactive changes. The phrase "A stitch in time, saves nine" applies even in software. Preparing for and maintaining changes that may negatively impact customizations in advance of those events allows for a longer development time to create a proper correction, rather than a quick fix that will not stand the test of time.

As we look into the future of ERP and the rapid involvement of AI tools, its important that we not forget to look into the customizations of the past to ensure they are ready for the changes that will come.