Posts
Written by Frederick Sperry - Validation Manager, QPharma
The management of custom databases does not need to be an onerous task. When taken seriously, one can justify the management of the details associated with the database as Good Business Practices. Even the elephant can be eaten – one bite at a time.
Initially, as in any other activity in the regulated industry, know your process. Identify the key parameters that user requirements have defined for the database. What are the macros supposed to be doing, or any critical connections or formulas expected to produce? Document the findings as an initial deployment of the system, and get a system user review and approval of the requirements for the database.
Validate your process. Document the settings and verify the any formulas, macros of interfaces do what they are supposed to accomplish. Adjust any settings that do not meet the needs of the end users. Then update your documentation, and get review and approval signatures of the documentation. Typically this is in the form of a System Design Specification, System Configuration or Functional Specification document. The title of the document is not important; the current information is the critical item.
After the ‘deployment’ of the database keep the documentation current. The database configuration and settings are liable to change over the course of normal system usage. Keep track of the changes and periodically update the system documentation, and obtain the crucial user or management review, approval and sign off of the updated system settings.
Keep current with the data and database and embrace the new era paradigm shift from documentation to information. The documentation must empower the system users to be able to use the information as knowledge. In this new millennia day and age of information, knowledge is truly power.
The management of custom databases does not need to be an onerous task. When taken seriously, one can justify the management of the details associated with the database as Good Business Practices. Even the elephant can be eaten – one bite at a time.
Initially, as in any other activity in the regulated industry, know your process. Identify the key parameters that user requirements have defined for the database. What are the macros supposed to be doing, or any critical connections or formulas expected to produce? Document the findings as an initial deployment of the system, and get a system user review and approval of the requirements for the database.
Validate your process. Document the settings and verify the any formulas, macros of interfaces do what they are supposed to accomplish. Adjust any settings that do not meet the needs of the end users. Then update your documentation, and get review and approval signatures of the documentation. Typically this is in the form of a System Design Specification, System Configuration or Functional Specification document. The title of the document is not important; the current information is the critical item.
After the ‘deployment’ of the database keep the documentation current. The database configuration and settings are liable to change over the course of normal system usage. Keep track of the changes and periodically update the system documentation, and obtain the crucial user or management review, approval and sign off of the updated system settings.
Keep current with the data and database and embrace the new era paradigm shift from documentation to information. The documentation must empower the system users to be able to use the information as knowledge. In this new millennia day and age of information, knowledge is truly power.
No comments:
Post a Comment