What does AS9100 mean when it says you must establish a process to do X?

[Tyler]

I think you are imagining requirements that are not there, as even many 3rd party auditors do.

Perhaps you are right. Although, the term "process" bears a lot of weight in the standard because of the emphasis on "The Process Approach." It would be a lot clearer if they used a phrase like "your system's processes must ensure that...".

Even if they had said "recall and take action" it might have made more sense - just "recalling" ain't a process in most folks eyes.

Thanks Peter. Whenever the standard uses this phrase, it is always in connection with a few isolated requirements. I have always thought of processes as being much larger in scope than that.

 

[thumphrey03]

I would interpret that statement as saying you must have a written, version controlled procedure to address the specified process.

 

[Mike S.]

I would interpret that statement as saying you must have a written, version controlled procedure to address the specified process.

If you mean the statement "The organization shall establish, implement, and maintain a process for the recall of monitoring and measuring equipment requiring calibration or verification." then you are creating requirements that do not exist.

 

[thumphrey03]

If you mean the statement "The organization shall establish, implement, and maintain a process for the recall of monitoring and measuring equipment requiring calibration or verification." then you are creating requirements that do not exist.

Auditors will request to see where the above is addressed. What evidence will you show them you're in compliance in the above scenario?

 

[Mike S.]

Auditors will request to see where the above is addressed. What evidence will you show them you're in compliance in the above scenario?

Look, maybe 9 out of 10 people WILL have a written procedure to accomplish this, but it IS NOT required to be written. When ISO/AS really wants something to be written they say so very clearly i.e. "...shall be available and be maintained as documented information", etc. Otherwise to interpret it as though a shall is in there is just plain wrong.

If you can't think of a way to show something is being done without a document I would suggest you aren't trying hard enough.

 

[Kronos147]

Perhaps you are right. Although, the term "process" bears a lot of weight in the standard because of the emphasis on "The Process Approach." It would be a lot clearer if...

...they said controlled program.

I'm not sure you need KPI's for calibration. (We do at the machine shop, but that's just us. Because we let it go too many times in our distant past.)

Thanks Peter. Whenever the standard uses this phrase, it is always in connection with a few isolated requirements. I have always thought of processes as being much larger in scope than that.

They have been refining the "process approach" for a long time now. In ISO 9001:2000\AS9100 Rev. B, it was a whisper. It got a little louder in Rev. C, and more prescriptive in Rev. D, yet it's still not 'effective,' IMO.

The standard touches upon "Processes" in several places:
0.1 General, 0.2 Quality Management Principles, 0.3.1 Process Approach: General, 4.4.1 QMS and its Processes, 5.1.1 Leadership and Commitment: General, 5.3 Organizational Roles, Responsibilities and Authorities, 6.1.2 Planning: Actions to Address Risks and Opportunities, 7.1.4 Environment for the Operation of Processes, 8.1 Operational Planning and Control, 9.2.2 Internal Audit, 9.3.2 Management Review: Inputs

Where the standard fails is in 0.3.1 where they say the standard "promotes the adoption of the process approach." Why not say "system must be in conform with the process approach" in 4.4.1? Why not reference ISO9001_2015_Guidance_on_the_Process_Approach?

Auditors will request to see where the above is addressed. What evidence will you show them you're in compliance in the above scenario?

If you have a controlled program for keeping devices calibrated or verified (IAW AS9100 7.1.5, and it can pass an (effective) internal audit, then you should be good.

 

[Tyler]

They have been refining the "process approach" for a long time now. In ISO 9001:2000\AS9100 Rev. B, it was a whisper. It got a little louder in Rev. C, and more prescriptive in Rev. D, yet it's still not 'effective,' IMO.

I have had a pretty good experience with the idea of the process approach. It seems like a convenient way to draw lines and boundaries around the main functions within your organization. I work for a small machine shop, so our organization is not that complex. We have always thought of processes as being comprised of procedures which are in turn comprised of tasks (i.e., Process -> Procedure -> Task). Each step down you get more detailed. This works for us but I can only imagine what it would be like at a large and complex organization; I am sure there are more than three layers when it comes to documenting the management system of a large organization.

 

[thumphrey03]

Look, maybe 9 out of 10 people WILL have a written procedure to accomplish this, but it IS NOT required to be written. When ISO/AS really wants something to be written they say so very clearly i.e. "...shall be available and be maintained as documented information", etc. Otherwise to interpret it as though a shall is in there is just plain wrong.

If you can't think of a way to show something is being done without a document I would suggest you aren't trying hard enough.

I completely understand what you're saying, but unfortunately auditors don't think that way. We would get a minor nonconformance.

 

[Kronos147]

I completely understand what you're saying, but unfortunately auditors don't think that way. We would get a minor nonconformance.

In an internal audit, there was a function that I was thinking was at risk of being lost due to people leaving the organization. The auditee challenged me to watch the steps. He then asked me to have two other people do the same thing, and see if through training if everyone didn't do the same steps.

Lo and behold, they all did. No document needed (process owner decision).

When two of those people left, I picked up part of their roles, and I was the process owner for a while. I documented it.

Remind the auditor it's your system, they have to make a case why it's not effective. No shall? Consider it an OFI.

You only have so many resources. You address these decisions through the scope of your relevant interested parties, and the risks and opportunities of your context. Do what is most important first.

 

[Peter Fraser]

I have had a pretty good experience with the idea of the process approach. It seems like a convenient way to draw lines and boundaries around the main functions within your organization. I work for a small machine shop, so our organization is not that complex. We have always thought of processes as being comprised of procedures which are in turn comprised of tasks (i.e., Process -> Procedure -> Task). Each step down you get more detailed. This works for us but I can only imagine what it would be like at a large and complex organization; I am sure there are more than three layers when it comes to documenting the management system of a large organization.

Tyler

I would suggest looking at it slightly differently: a process is "work", ie "doing things". A process is made up of steps or tasks. You describe the process, or tasks, in a procedure, or SOP, or Work Instruction. If necessary you write it all down. But the process exists, and work gets done, even if you don't have anything in writing.
For example, in some one-man bands, there may be no written procedures because the boss knows what to do all the time. But he will be following a procedure ie a specified way to carry out a process or task, even if the specification is in his head. That is why bigger organisations need to define their processes, so that when someone leaves it is easier for the new start to know what to do. A process description, or a process flowchart, would be a procedure. So a "process" is different from a "process description", and it was a "process" that the standard was asking for (even if it got the concept wrong!)