I've worked in two different environments that were ISO-9001 compliant. In the first one, we tracked only PROCESS non-conformances in one tracker and PRODUCT nonconformances were tracked in a defect tracking system. I don't see any guidance in the standard on this and my instinct is to fall back to the concept that since any QMS has to make sense for your business, that it's ok to track product and process nonconformances in the same place. Does anyone else have similar experiences?
Corrective Action Tracking for Product and Process in the same system?
- Thread starter ISO_Man
- Start date
Define 'tracker'. Whether or not you want them combined is entirely a company choice. I tend to recommend a combined database.
For example, one could have a database which tracks all corrective actions, customer complaints and potentially other information. The main aspect would be that there be an effective set of filters to be able to extract appropriate reports.
As an example re: databases
This forum runs on a single database because it is small enough to do so. Take a look at all the different things it tracks - Threads, individual posts, user names, passwords, 'media' items, post attachments, etc. The many different pages you see and their content are nothing more than 'reports' from that single database.
If you are a very big company, you may actually want a number of smaller distributed databases, but the concept is the same. It is the filters/reports which are the important factor.
Whether you use database(s) or use paper, or one or more spreadsheets is entirely up to you.
For example, one could have a database which tracks all corrective actions, customer complaints and potentially other information. The main aspect would be that there be an effective set of filters to be able to extract appropriate reports.
As an example re: databases
This forum runs on a single database because it is small enough to do so. Take a look at all the different things it tracks - Threads, individual posts, user names, passwords, 'media' items, post attachments, etc. The many different pages you see and their content are nothing more than 'reports' from that single database.
If you are a very big company, you may actually want a number of smaller distributed databases, but the concept is the same. It is the filters/reports which are the important factor.
Whether you use database(s) or use paper, or one or more spreadsheets is entirely up to you.
We are a fairly large company with many different product types (not just skus. we have complex instruments and small one time use devices).
We couldn't put all nonconformances in one data base even if we tried, the sources and types of data are far too disparate. but your current company may be small enough with a product base where it makes sense to put everything in to one database.
We couldn't put all nonconformances in one data base even if we tried, the sources and types of data are far too disparate. but your current company may be small enough with a product base where it makes sense to put everything in to one database.
Technically that could be resolved. I have worked with large companies that not only had multiple databases, but also had them replicated and synchronized in various cities around the world in part so that a significant failure (equipment, natural disaster(s)) of one location, or even 2, at the same time, wouldn't bring them down. The required various queries (aka reports) are the important part. The way it was set up, queries often drew from multiple different databases.
JoshuaFroud
Involved In Discussions
The system I have implemented at my current company tracks both process and product issues in the same system. There is however a "Cause Category" that is selected up front which is used to differentiate the issues, this is where "product" and "process" issues are broken down. The categories are things like, "Component Failure", "Design Issue", "Management Review Action" "Post Market Surveillance", this is where the issue was identified. It is not a root cause but the initial failure or point at which the failure is found.
The rest of the system is generic enough to allow both processes to flow through.
The rest of the system is generic enough to allow both processes to flow through.
M
malasuerte
Short answer is yes, you can track in different dbs.
Key things for consideration: extraction(stated already); record retention; ability/access to retrieve data; traceability; controls;
Key things for consideration: extraction(stated already); record retention; ability/access to retrieve data; traceability; controls;
