Our comany currently has a computerized "customer complaint" type system in place. I would like to somehow either add to it (this is an option) or add another form such that it is easy to go back and see all the cases where a change was needed in a process or work instructions.

Hi Harold,

When you say it is a computerized, is it a software or in Microsoft Excel ? Are you hinting on Audit Trail when you say that you want to go back in the software ? Pls clarify.

Qualityalways
:)

Hi, I don't quite get it either. We also have a complaint registration in our ERP software, but the analysis of the raw data (problem, cause, cost etc.) is still to be done by someone. Why would you like to have specifically any work instruction change in this system? The actions that need to be taken after cause analysis do not automatically imply a change in procedures and/or instructions. The reasons for changes in such documents need to be in the control/issueing function of those documents. Besides that there are other reasons than complaints to change documents. I'd say that actions resulting from complaint analysis should be registered. When an action has been taken it should refer to that registration for clarity in future times.

Kind regards

I don't thing I did a very good job of explaining either. Let me try again. We have a document that customer service fills out with customer complaints, it is actually a program (called a Customer Response System). It is then possible to list the complaints by the company name. I can add a field in there for Preventative Action Request rather than adding an additional form.

I was interested in a simple way to organize complaints, CAR's, and PAR's. I really have no idea how these are typically done (new to this all). Not sure if putting them all in the same form would be confusing.

I'm also not sure how often PAR's typically end up getting filled out in a "normal" company.

This all may be something I just have to work with, trial and error type thing.

I'm not sure if this will help, but, here goes:

Software companies typically capture complaints from customers in a "bug tracking system," essentially a big filing cabinet of electronic complaint and CAR forms. They organise it such that they can list bugs reported by customer, by product line, by product version number, date reported, fix response time, severity (critical, major, minor), etc.

The corrective action is on the same form, so the record of the customer complaint and what the company did in response is all in one place. The better systems enable several similar complaints to be linked so that the one corrective action serves them all.

The corrective action part of the form tracks the current owner of the problem, its status (reproduce the problem, diagnose root cause, fix, test, deliver, etc) and notes amongst programmers, testers and managers on the progress of diagnosis and fix.

The best systems include a field where the engineer determines where in the process the fault entered the product - badly written requirement, poor design, lousy programming, inadequate testing, customer did something daft, etc. This is based on their standard development lifecycle and helps determine long term preventive actions, which are typically handled outside the "complain and fix" cycle because they usually involve changes to the process itself, not the design and code. For example, if the data indicate that lots of customer-found defects are due to poor requirements, that may indicate that improvements are necessary in the requirements specification process.

Just my 2c, hope it might help your thinking,
Patrick