View Full Version : Internal Auditing: New Product Launch
Anerol C 16th October 2007, 01:32 AM Hi!
I'm looking for advice on what looking for on an internal audit that has been scheduled; there is a prototype being built in our facility; the product is a "huge" assembly (just one assembly - almost finished); our plant is not designing;
I think that I should look for prototype project status; functional test records completed; pending action items to be completed for other departmens; this is not a production line, no control plan and pfmea available,:bonk: What else I can looking for to verify that the "process to introduce new products is working fine ?
:thanx:
AC
Stijloor 16th October 2007, 08:05 AM Hi!
I'm looking for advice on what looking for on an internal audit that has been scheduled; there is a prototype being built in our facility; the product is a "huge" assembly (just one assembly - almost finished); our plant is not designing;
I think that I should look for prototype project status; functional test records completed; pending action items to be completed for other departments; this is not a production line, no control plan and pfmea available,:bonk: What else I can looking for to verify that the "process to introduce new products is working fine ?
:thanx:
AC
Hello Anerol,
Prototype? No prototype control plan required? No PFMEA (yet)?
I don't know Anerol, it does not look like a good start to me..
Well, here are some audit ideas (proceed with caution...)
List all the requirements for this prototype. (Input)
Were all requirements for the prototype met? (Output)
If not, explore the controls used for this process.
Verify all parts of this prototype process.
I'm sure you'll come up with additional discoveries that require further exploration.
In addition, look here (http://elsmar.com/Forums/fileslist.php?mode=allfiles&sortby=filename&pageamt=2&criteria=+apqp) for more (APQP) audit ideas.
Stijloor.
Miner 16th October 2007, 08:22 AM I recommend auditing the records associated with the original contract review for this prototype.
Anerol C 16th October 2007, 11:06 AM Well the reason that there is not Control Plan/PFMEA is because this industry is not automotive, it is ideal to have it but as this is not a requirements they are not in place:(;
Should I look for APQP even when this is not a requirement?:confused: As far as I know just a Gantt chart in Microsoft Project to see the status of advance and we are not designing,
Thanks for your comments,
Anerol
Jeff Frost 16th October 2007, 11:23 AM Have you though of just using the requirements from ISO 9001:2000 7.3 Customer-related processes, Clause 7.3, Design and Development, and 7.5, Production and service provision?
Also look at these requirements related to the product during audit:
- What are the contractual requirements imposed by the customer (customer requirements)?
- What are the Mexican Federal Government requirements for product being produced (regulator/statutory requirements)?
- What are the regulator/statutory requirements for receiving country of the product being produced and exported (if applicable?)
Stijloor 16th October 2007, 11:30 AM Well the reason that there is not Control Plan/PFMEA is because this industry is not automotive, it is ideal to have it but as this is not a requirements they are not in place:(;
Should I look for APQP even when this is not a requirement?:confused: As far as I know just a Gantt chart in Microsoft Project to see the status of advance and we are not designing,
Thanks for your comments,
Anerol
Hello Anerol,
Even though your organization is not "automotive", you could benefit from APQP guidelines. But that's obviously your choice. Jeff Frost gives excellent suggestions to include the requirements of ISO 9001:2000, clauses 7.1, 7.2 and 7.3. The main question remains: What are the requirements? That's what you audit against.
Stijloor.
Anerol C 24th October 2007, 03:25 PM Here are some of the finding;
Let me know your opinion.
1.-There is a procedure where a "release process sheet" is called but nobody is taking care of it, the leader of the project tells that is not his responsiblity is Area Engineer responsibility.
2.-There is a planning on Prototype built; with status and progress, also a list of open and closed items, which I think it is fine, but there is not a planning on how the Prototype will be integrated on the production line, no timing on when they will get the fixture neither on lay out completion, engineers know what they need but not timing is established.
3.-The monitor and measurement records are not complete and there are some that are stating that some components are not to print, I need to look out if there is a deviation approved or an ECN.
I don't think we are performing very well.
Anerol:nopity:
Jeff Frost 25th October 2007, 11:56 AM Looks like you have identified some of the issues with this process and at this point you should be linking them to the ISO 9001 standard requirements. If it don’t work or does not meet the Standard, or organizational procedures then the findings of nonconformity should recorded and a CAPA opened.
Some times organizations forget that they must first meet the requirements of the Standard and also their own documented procedures and work instructions. Internal auditors should write findings of nonconformity against the Standards requirements when they are observed.
AndyN 25th October 2007, 12:03 PM Here are some of the finding;
Let me know your opinion.
1.-There is a procedure where a "release process sheet" is called but nobody is taking care of it, the leader of the project tells that is not his responsiblity is Area Engineer responsibility.
2.-There is a planning on Prototype built; with status and progress, also a list of open and closed items, which I think it is fine, but there is not a planning on how the Prototype will be integrated on the production line, no timing on when they will get the fixture neither on lay out completion, engineers know what they need but not timing is established.
3.-The monitor and measurement records are not complete and there are some that are stating that some components are not to print, I need to look out if there is a deviation approved or an ECN.
I don't think we are performing very well.
Anerol:nopity:
Sounds to me like your process isn't well defined or documented. So, what happened? Perhaps doing an audit isn't worthwhile, since your management probably know that their prototype process is broken.
Anerol, is this the case? It's not really much use to do an audit if the process is not well defined, understood or implemented first. But you can use this opportunity to get your mgmt team to address it!
Jim Wynne 25th October 2007, 12:27 PM Looks like you have identified some of the issues with this process and at this point you should be linking them to the ISO 9001 standard requirements. If it don’t work or does not meet the Standard, or organizational procedures then the findings of nonconformity should recorded and a CAPA opened.
Some times organizations forget that they must first meet the requirements of the Standard and also their own documented procedures and work instructions. Internal auditors should write findings of nonconformity against the Standards requirements when they are observed.
The standard is not what must be met first. The requirements of the standard should be integrated into "the organization's" documentation such that direct reference to the standard is obviated.
Sounds to me like your process isn't well defined or documented. So, what happened? Perhaps doing an audit isn't worthwhile, since your management probably know that their prototype process is broken.
Anerol, is this the case? It's not really much use to do an audit if the process is not well defined, understood or implemented first. But you can use this opportunity to get your mgmt team to address it!
If the object of internal audit is to verify (or falsify) the working hypothesis that a functioning system is in place, I think that doing the audit in this case was useful, and served its purpose well. One compelling bit of evidence that there's a major problem in this case is this:
There is a procedure where a "release process sheet" is called but nobody is taking care of it, the leader of the project tells that is not his responsiblity is Area Engineer responsibility.
When a requirement hasn't been met because the responsibility and authority for fulfilling it hasn't been explicitly defined, you know something ain't right, and it's time to go back to the proverbial drawing board.
Jeff Frost 25th October 2007, 03:26 PM Jim,
I must disagree with you on this one. Does the standard require that all process must be documented in writing by the organization? What if the organizations written procedure and work instruction does not meet the requirements of the standard? What if there is a process within the organization that is implemented through OJT but the standard does not require a written procedure or work instruction? What if a revision to a written procedure or work instruction results in a non-fulfillment of a requirement of the standard?
Auditors are always task to verify the organizations written description of the process is still in conformance to the requirement before he or she can audit the processes described within its written procedures and work instructions. Auditors are also tasked with verifying that undocumented but required processes conform to the requirements of the standard.
Or are you just saying that an organization should wait for the register to identify a non-fulfillment of a requirement of the standard because the orgaization only audited it procedures without regard to the requirements of the standard?
Jim Wynne 25th October 2007, 04:00 PM Jim,
I must disagree with you on this one. Does the standard require that all process must be documented in writing by the organization? What if the organizations written procedure and work instruction does not meet the requirements of the standard? What if there is a process within the organization that is implemented through OJT but the standard does not require a written procedure or work instruction? What if a revision to a written procedure or work instruction results in a non-fulfillment of a requirement of the standard?
Auditors are always task to verify the organizations written description of the process is still in conformance to the requirement before he or she can audit the processes described within its written procedures and work instructions. Auditors are also tasked with verifying that undocumented but required processes conform to the requirements of the standard.
Or are you just saying that an organization should wait for the register to identify a non-fulfillment of a requirement of the standard because the orgaization only audited it procedures without regard to the requirements of the standard?
I think maybe you misunderstood me. I said that the organization's documentation should be written such that all of the requirements of the standard are addressed. If that's the case, there's no need to refer to the standard in internal auditing, and in actuality, there isn't even a need to refer directly to the standard in the documentation itself (although some consider it helpful to do so). In the case of undocumented processes (which should be rare) then the requirements of the standard are tacitly invoked in the design of the process.
People need to avoid creating the impression that we do things because it's what ISO says we have to do. We should do things that make sense for our own situations, while honoring the standard as a basic framework for accomplishing the task. In the case of internal auditing, we should be trying to verify that the system works as designed, and if the system is developed with the ISO requirements integrated into it, there's no need to invoke the standard explicitly.
|
|