Process documentation is known for providing a foundation for process and quality improvements. Additionally, there are benefits in having process documentation for knowledge retention during employee turnover and new employee on-boarding. These are the standard benefits associated with process documentation and they are well known. Another set of less known benefits is realized by building process documentation to support system integration efforts.
Imagine you're working on a system integration project that doesn't require formal current state documentation. I have been on many of these projects and I have observed a large disconnect between the architects/technical designers, business users, and quality assurance testers.
- The business users have written the requirements but didn't understand how the data actually flows through the different systems.
- The requirements are handed-off to the developer who generally understands what needs to get done but cannot actually develop based on the requirements.
- The tester receives the requirements but cannot write end-to-end test cases because they don't display the complete picture and lack the necessary clarity.
How does the above scenario change if process documentation existed for the processes in question? Data flow diagrams could have been written at the business objective level to show hand offs and collaborations between systems. The process flowcharts provide details on system interactions, tables, and ETL business rules. The process flowcharts also aid the testers by providing a true understanding of the process allowing them to perform integration testing. These would be the initial set of documents needed to improve communication between the business and technical resources.
There is a great benefit to bridging the process documentation with the requirements. Enterprise Processes (level 0),Business Domain (level 1) and Business Process (Level 2) flows provide a foundation which business requirements can reference resulting in improved clarity.. The Sub-Process (level 3) flows would be used for detailed business and system requirements. Level 3 Sub-Process flows can also document business rules useful for ETL development. Finally, testers will now have a suite of documentation to leverage while writing test cases. Testing will not only occur to assure functionality meets requirements, but that the requirements meet the outlined business process.
Process documentation is rooted in process improvement and business transformation initiatives. However, there are big benefits to using process documentation in system integration projects to improve communication, development quality, and testing strategies.