Series on Internal Auditing

Series on Internal Auditing
Hi,
I would like to share my auditing experiences in the form of explanations on the NCR’s raised by auditors.
This would help the process owners to make sure that their processes are in compliance with the standards requirements. As internal auditors, these catchwords would help them identify non-conformance areas and write clear, unambiguous, and correct NC reports.
Kindly go thro the same and comment
Thanks
IA Catchword- series 1
1. A cause for concern
When you observe that the process is not adequately controlled and the trend of the compliance/product quality is deteriorating, it is a cause for concern. You may also find that there is an attitudinal problem and no actions are taken to contain the problem.

2. Acceptance criteria not specified
For any product/process being measured, there shall be a criteria/conditions which specify if the product/process is acceptable for further processing. This is applicable even for visual checking for attributes. The objective of this is to ensure that only processes/products which are acceptable are passed on further. Sometimes, the Inspector ignores/do not attach importance to the tolerances specified, stating that it will not affect the process/product. In such a case, Auditor shall identify as an observation and ensure that the acceptance criteria is reviewed, to reflect the existing conditions

3. Actions towards prevention of recurrence not evidenced
One of the important aspect of ISO 9001 is that actions shall be identified to prevent recurrence of chronic/repetitive problems. Invariably, many of those repetitive/chronic problems are not attended, either because they are minor in nature or solutions which calls for infrastructure improvement or just not analyzed. Auditor shall verify further if those problems have resulted in any customer concern or quality concern. in such a case, it is necessary to identify corrective actions to prevent recurrence.

4. Analysis of customer complaints not done
Continual Improvement is important for any Business growth. Towards this, one needs to collect information on the performance of the products/processes. Customer complaints offer an opportunity towards this. It is necessary, therefore to collect the customer complaints, collate the data with a view to analyze and in such a manner that probable causes are identified. Analysis of this data shall be done periodically, to elicit workable solutions. If the data is too trivial, and does not provide any meaningful causes, then also it is necessary to use the various analytical tools and arrive at a conclusion. Analysis shall be done thro' an investigation process and using various tools. The results of analysis shall be a list of controllable and uncontrollable factors and using a filtering technique, corrective actions shall be identified.

To be continued…………………

Preventive Actions
One of the difficulties in auditing a preventive action program is that some organizations don’t understand well the differences between corrective actions and preventive actions.

A corrective action is taken on a detected nonconformity to prevent it from happening again. An organization will first correct or contain the problem, and then determine its root cause so they can take corrective action to prevent its recurrence.

When we act to “prevent” a repeat of a detected nonconformity, that is full and complete corrective action, not preventive action.

Preventive action is when we anticipate a potential problem and take action to eliminate the possible causes and prevent the occurrence of the nonconformity.

Auditing a preventive action program begins with a review of the preventive action procedure required by ISO 9001:2008. Of course, an organization may choose to have corrective actions and preventive actions covered in the same documented procedure. This is acceptable as long as the requirements in both clause 8.5.2 and 8.5.3 are adequately addressed.

When a potential problem is identified, organizations must determine the action needed to eliminate the causes of the potential nonconformity and thereby prevent its occurrence. However, the action taken must be appropriate to the effects of the problem.

In other words, it would be acceptable to not take a preventive action if the anticipated problem is unlikely to happen, would have little impact, and would be easily detected. If a potential problem is low risk, the business decision may be to not attempt to prevent it.

However, if there is a need, the organization must determine and implement the appropriate preventive action. Records must be kept of the results. The action taken must be reviewed to assess its effectiveness in preventing the potential problem.

The best time to take preventive actions is early in the product cycle, e.g., performing Failure Mode Effects Analysis and conducting Design Reviews. However, these actions are integral to the process and won’t necessarily be captured on preventive action forms.

As a consultant to two different Software companies, I had an opportunity to interact with two different Certification Bodies. In both the companies, the core process happens to be Software development, specifically Project Planning, Developing codes, code testing, code reviews, and releasing the product. While one of the Certification bodies insisted that the Cl. No. 7.5.2 - Validation of Processes, cannot be excluded, the other body made us to exclude the same.
In my opinion, the exclusion is not applicable for software process, due to the basic process of coding which can be verified only after the total product is released, since the coding is always done in bits and pieces.
Any comments please,
Thanks