Customer Complaint leading to Corrective Action vs. Change Request

R

RLewing

#11
Distinction between correction and corrective action

In our company Change Request (we call it Discrepancy Report) directs a CORRECTION. That is fixing the specific bug in our SW product.

Please make a distinction between 'correction' and
CORRECTIVE ACTION which may or may not be started (based on Root Cause Analysis) to change the process (procedures, work instructions, forms) so that similar causes would not produce new similar bugs in future versions.

PREVENTIVE ACTION may be started if we notice e.g. statistically that some type of bug is repeating, or that we do continually fixes to same part of code.
 
Elsmar Forum Sponsor
M

madannc

#12
Re: Distinction between correction and corrective action

In our company Change Request (we call it Discrepancy Report) directs a CORRECTION. That is fixing the specific bug in our SW product.

Please make a distinction between 'correction' and
CORRECTIVE ACTION which may or may not be started (based on Root Cause Analysis) to change the process (procedures, work instructions, forms) so that similar causes would not produce new similar bugs in future versions.

PREVENTIVE ACTION may be started if we notice e.g. statistically that some type of bug is repeating, or that we do continually fixes to same part of code.
Lifecycle of a non conformance (whether it be software problem, hardware problem, process problem)

Non conformance noted (all details available at time [when, where, who, what etc etc] recorded)

Correction put in place, immediate fix e.g. correct software installed, new part fitted etc etc

Investigation (including impact analysis - see earlier post) record finding of investigation and all data e.g. trend analysis, pareto, cause and effect etc etc

Root Cause identified from analysis - process not followed, training, process incomplete etc etc

CA proposed - Action that will prevent recurrence, process changed, training given, CCP (crittical control point) put in place, process introduced etc etc

CA Agreed - proposal reviewed along with investigation and findings by cross functional team

CA implemented - CA owner implements according to plan and by agreed date

Effectivity Check assigned - criteria put in place to check the CA has been effective, e.g. after 2 months check NC database for similar (do another trend) basically assign criteria for pass e.g. no further occurences = pass and time span required before check

As an easy example

The Quality Train 007 fails to stop at complianceville over shooting station by 300 metres on the 18 Feb 08 at 15:49 GMT

Correction - replace brakes on Quality Train 007

Investigation; shows that service of brakes is due every 12 months, 007 was serviced Aug 07 (approx 6 months ago), but investigation has shown that the Quality Train Fleet (if right word for a group of trains) has doubled its operation now running twice as much since Sept 07. Trending shows this is first occurence.

CA - Whole fleet of Quality Trains to have brakes serviced/replaced after 4 months. check reveals that 3 other Quality Trains will require replacements with this new regime. Implement change to PMM (Preventive Maintenance Manual) to change brakes after 4 months, update all schedules (10 trains affected 001 - 010). Implement change to operation of train schedules so if reduced or increased service requirements are considered - additional box to be added to request form that requires completion prior to agreement of change to operation.

Effectivity - Check after 4 months that schedule is being followed and no further instances of failed stopping has occurred.

Equally the investigation for this could have shown that there was a supplier change to save money on train brakes and the failure happened after this... I guess what I am saying is that only with thorough/good investigation can determine root cause and implement (via change) effective CA's

hope this clarifies a little

cheers Nigel :)
 
M

madannc

#13
Re: Distinction between correction and corrective action

PREVENTIVE ACTION may be started if we notice e.g. statistically that some type of bug is repeating, or that we do continually fixes to same part of code.
Not sure if this is Preventive... IMHO PA is prevention of NC, here the bug has occurred therefore I would not see this as PA.

If you had not experienced a problem with a particular bug yet and discovered that a new piece of software for checking code will highlight and bugs or issues, the implementation of this would be PA, and also a potential cost saving in not having a peer do a code walk through... (after suitable V&V)... struggling a bit because software is not my area
 
Last edited by a moderator:
R

RLewing

#14
Madannc's description of the lifecycle is very good for hardware. :applause:

But software is confusing... :confused:

Production of SW can be defined as just the replication of CD's. Hence all the work done before that is design process.

So even the smallest bug can not be corrected by fixing production or the one piece of product that was observed defect. It always needs design work. Errors in design work appear as bugs (and they appear in every copy). Bugs can be made less frequent by corrective actions in the process (add certain tests, peer reviews...).

Re preventive action: Each bug may have received the correction + corrective action treatment. However, statistics over a time may show that some type of bugs still appear too often in some certain area. Then, it is time for PA.

I admit, both of these this are areas where wastly different opinions exist. It is basically about level of abstraction you choose (and that you define in your procedures). The principles are in any case very much same.

Generally it is like with root cause analysis. We Quality Pros should always take one more step than a layman would, because our satisfaction comes from making the world a better place.
 
Last edited by a moderator:
M

madannc

#15
Re preventive action: Each bug may have received the correction + corrective action treatment. However, statistics over a time may show that some type of bugs still appear too often in some certain area. Then, it is time for PA.
This sounds like it is acceptable or expected to get a number of bugs when producing software and it is also expected that not all bugs will be discovered prior to release...

If statisically monitoring after release to prevent further occurence would this not be a CA?

Or am I reading it wrong and that post release you are finding to many bugs during smoke testing, verification or validation, in which case would it constitute a failure and the correction to the software be part of the project plan and be handled by "Design" NCR?

If a review of the design NCR's shows that a particular bug is recurring to often (suggesting there is an acceptable level?) the remedy of this would still be CA as it is preventing recurrence. However if monitoring an "acceptable" level and you see a trend approaching a breach of this, then putting something in place to prevent this breach would be a PA

To go back to the train example, if the failure was caused due to a software change that caused a delay in brakes being applied, the fix would still be a CA.

Thinking of a PA perhaps with vigilance you became aware of the problems your rival company was having with its brakes and although you have not experienced this issue implementing a review of current software that controls the braking system and subsequent changes would be a PA as this has not occurred and you are truly preventing occurence.
 
Last edited by a moderator:
R

RLewing

#16
This sounds like it is acceptable or expected to get a number of bugs when producing software and it is also expected that not all bugs will be discovered prior to release...
Wery much so. You don't have much experience in SW, do you? A software which is more complicated than the traditional excercise of printing "Hello world!" will always have bugs, at least the users will use it in another way or another hardware than intended.

When the software has 100000 lines of code, handled data consists of a 3D model of human and the user can interactively adjust a hundred parameters, then "testing has more alternative paths than atoms in universe". We can not have more than statistical confidence that all bugs/risks are sufficiently controlled. We try hard to make it as good as possible but the fact remains that it needs to go out to customers with some remaining issues. Otherwise the customers would not have any tools to do their job as well. Users know it and accept the fact. You probably use standard office software? Don't you accept that it sometimes fails?

Happy to say that despite of some remaining bugs, our product is world #1 for the specific intended use. Both in numbers and in polled customer satisfaction.

I won't join the :argue: of terminology game. But let me reformulate: lets just try take one step deeper in the root cause, no matter how we call the objects and processes. And to make auditors and inspectors happy, lets document our words and processes as we use them.

Cheers
Raimo
 
M

madannc

#17
You don't have much experience in SW, do you? A software which is more complicated than the traditional excercise of printing "Hello world!" will always have bugs, at least the users will use it in another way or another hardware than intended.
No I don't, but I am learning fast

When the software has 100000 lines of code, handled data consists of a 3D model of human and the user can interactively adjust a hundred parameters, then "testing has more alternative paths than atoms in universe". We can not have more than statistical confidence that all bugs/risks are sufficiently controlled. We try hard to make it as good as possible but the fact remains that it needs to go out to customers with some remaining issues. Otherwise the customers would not have any tools to do their job as well. Users know it and accept the fact. You probably use standard office software? Don't you accept that it sometimes fails?
Image aquisition is something I have a little experience of and 3D (and 4D) reconconstruction of 2D imaging using back projection, although not technically adept at coding I am aware of how these images can be used for treatment planning and the consequences of setting up a treatment plan incorrectly. When my PC freezes or crashes I may lose a report/spreadsheet that although inconvinient will not cause me any health issues. However if being treated for cancer using IGRT (Image Guided Radiation Therapy) and the plan is out non cancerous cells in my body are at risk. I understand that not all bugs are safety issues, but testing vigoursly for safety is a must.

Please note I am not suggesting that you do not perform risk analysis and have RCM's etc I am just trying to show that likening microsoft office to a medical device is not relevant.


Happy to say that despite of some remaining bugs, our product is world #1 for the specific intended use. Both in numbers and in polled customer satisfaction.
Congratulations, definately something to be proud of, is your product in Radiation therapy?

I won't join the :argue: of terminology game. But let me reformulate: lets just try take one step deeper in the root cause, no matter how we call the objects and processes. And to make auditors and inspectors happy, lets document our words and processes as we use them.
Nor would I expect it, I know that sometimes the regs can seem restrictive or archaic but they are there to protect users and patients, and I commend RCA not just for the regs but but for better/safer products.

:agree: :truce:

cheers Nigel
 

Jen Kirley

Quality and Auditing Expert
Staff member
Admin
#18
I won't join the :argue: of terminology game. But let me reformulate: lets just try take one step deeper in the root cause, no matter how we call the objects and processes. And to make auditors and inspectors happy, lets document our words and processes as we use them.
With all due respect, if you are serving the medical community and have/will be registered to a standard like ISO 13485, it could behoove you to align with their terminology and requirements.

Structured Software Quality Management is pretty new in the QA disciplines, and I am not an expert so I will refer you to NASA, MIT, and the FDA.
 
W

w_grunfeld

#19
Hi,

If a customer complaints about a non-conforming device, should I then assign a Corrective action to fix this problem or should I raise a change request? The device is a software and at the moment any problems detected by the customer, we will record in a customer feedback form, raise a CAPA, then raise a change note which I dont think should be the right process. When does an action on a device considered a change and when is it considered a corrective action? It seems that CAPA and change control runs parallel to each other, please correct me if I'm wrong.

Thanks for your feedback
hrobot
A CAPA is not necessarily a change, especially in a software product. A CAPA can be closed after the bug is recorded , analysed and determined how and when to fix it. A change on the other hand would be issued when a new version is to be released, and it may address several bug fixes. So you may have many CAPAs that would all resolve into one change.
Depending on the iindustry,, most software companies won't even have a formal CAPA, they may use in lieu of it a bug tracker tool .New versions (changes) are typically marketing driven and may include functional changes as well. For a critical bug however, there may be need for an immediate new release and if such is the case the CHANGE and the CAPA are the same
 
R

remsqa

#20
:agree:
Hi,

If a customer complaints about a non-conforming device, should I then assign a Corrective action to fix this problem or should I raise a change request? The device is a software and at the moment any problems detected by the customer, we will record in a customer feedback form, raise a CAPA, then raise a change note which I dont think should be the right process. When does an action on a device considered a change and when is it considered a corrective action? It seems that CAPA and change control runs parallel to each other, please correct me if I'm wrong.

Thanks for your feedback
hrobot
Hai


No as per the ford System of problem solving .

The change request is a part of the G8D,and hence any non conformance or customer complaint or customer dissatisfaction .Should be handled with the G8D only.
 
Thread starter Similar threads Forum Replies Date
M Reduce occurrence rating based on the PMS data and customer complaint data ISO 14971 - Medical Device Risk Management 2
J Customer Complaint & SCAR, false data Nonconformance and Corrective Action 14
J Customer Complaint Response 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 3
S How to treat a customer complaint ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 7
PhilM Nonconformance report, Customer complaint investigations and RMAs ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 8
G Problem Resolution Report Monitoring - Customer complaint or PRR as general motors use Customer Complaints 12
R Does an RMA = a Customer Complaint Customer Complaints 4
G Customer complaint over a Reference Dimension Manufacturing and Related Processes 9
E Is there an Automotive Customer Complaint Index? IATF 16949 - Automotive Quality Systems Standard 3
R In a software development company: Is every bug reported by the customer a complaint? ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 27
E Corrective Action or Customer Complaint ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 16
T Decontamination responsibility on customer complaint investigation Customer Complaints 4
N Possibly worlds first customer service complaint Supply Chain Security Management Systems 0
A What is a Customer Complaint? (ISO 9001:2015) ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 9
M Should Potential Customer Complaint Outcome Define Registrar NC Rating? ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 8
J FDA definition of a complaint - Customer orders spare parts 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 5
P Customer Complaint Definition - Food Distributor Customer Complaints 5
R Customer Complaint - Samples vs. Removal - FDA Requirements 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 2
Moncia Customer Complaint Procedure example needed Document Control Systems, Procedures, Forms and Templates 1
C Medical Device Malfunction - Customer Complaint - Response vs. Correction Other US Medical Device Regulations 3
T PPAP - Complaint from a Tier One customer concerning Product Dimension IATF 16949 - Automotive Quality Systems Standard 26
Q Customer Complaint Vs. Nonconformance - CAPA SYSTEM Customer Complaints 2
L Creating a xlsx Customer Complaint file to track Complaints Excel .xls Spreadsheet Templates and Tools 2
N Customer Complaint - Rapid Response Containment Procedure Customer Complaints 4
J Customer Complaint - PPAP - Issues not called out on the print APQP and PPAP 3
R Customer Complaint/Nonconforming Product Inquiry ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 4
D Can anyone share a Customer Complaint procedure not requiring logging complaints ? ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 5
P Customer Complaint Preventive Action Assistance Preventive Action and Continuous Improvement 3
Q When to issue a Customer Complaint related to efficacy of a Medical Device? ISO 13485:2016 - Medical Device Quality Management Systems 3
S Do I need to initiate a Customer Complaint for Engineering Samples? Customer Complaints 4
A Customer Complaint - Incident Reporting Hardcopy Signoff Customer Complaints 8
B Analysis & Closure of a Customer Complaint Customer Complaints 6
C Customer Feedback, Satisfaction, Complaint Procedure and Measurement Customer Complaints 8
N Closed Customer Complaint Response Form Examples? Customer Complaints 3
J Damaged Parts in Customer Returns - Complaint Investigation? ISO 13485:2016 - Medical Device Quality Management Systems 9
D Is an NCR required in this Customer Complaint scenario? Nonconformance and Corrective Action 6
B Categorization of Customer Complaint: Making Customers feel they are Top Priority Customer Complaints 4
B Understanding the attached sample Pareto Chart for Customer Complaint Quality Tools, Improvement and Analysis 20
J Should I file a Customer Complaint as a Nonconforming Material Report or a CAP? Nonconformance and Corrective Action 5
R Help defining Eyewear Customer Complaint Categories Customer Complaints 5
K Audit NC - No evidence of a full 5 Why Analysis for the Customer Complaint Problem Solving, Root Cause Fault and Failure Analysis 8
somashekar What if a non EU customer makes a complaint to NB ? EU Medical Device Regulations 2
R Everest Customer Complaint System by Lynk Software US Food and Drug Administration (FDA) 1
T Is a Nonconformance Report required for every Customer Complaint? ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 18
J Who should accept the samples of Customer Complaint products ? ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 3
S Data Flow diagram for a Customer Complaint System - Help wanted Customer Complaints 6
B Small Company Customer Complaint System ISO 13485:2016 - Medical Device Quality Management Systems 2
L Internal Audit to Focus on Customer Complaint Re-occurrences Internal Auditing 4
W Re-Evaluating Corrective Actions - Recurrence of a Customer Complaint Nonconformance and Corrective Action 7
P Customer Complaint due to unanswered telephone during audit Internal Auditing 16

Similar threads

Top Bottom