ISO to AS9100 nightmare

Elsmar Forum Sponsor
From what I know, we are not 'regulated' by any authority that imposes QMS requirements,
We are a job shop, so ultimately any requirements that come to us are specific to the customer contracts relating to the job, and are always changing based on the work we are currently doing
The wording trips me up at the 'stat/reg qms requirements'. How are those different than customer regulatory requirements such as RoHS or REACH or something similar? From what I understand, those don't impose any requirements relating to the QMS.



For the second answer, our flow chart has the name of the process, the inputs and outputs, the connection to other processes, and the owners. But owners are not defined by name, rather by position. So Production would have the process owner "Production Manager". I'm assuming this is enough to meet the requirement, since there isn't anything mandating that the process owners be named.

Is this an adequate interpretation?

Your help is much appreciated
As a job shop, most likely all of the regulatory requirements will be flowed down from your customer.
 
ITAR compliance in the context of an organization in the Aviation, Space and Defense supply chain is a commonly mentioned legal requirement which might affect you.

Not necessarily an additional regulation, but in a sector where counterfeit material and components are such a serious risk, failure to properly manage the origin and traceability of metal parts could, in an extreme case, bring the feds knocking on your door.
I see. I could write this into our quality manual:
"The organization is registered with the Controlled Goods Program. The requirements relevant to GCP compliance are addressed, and can be found in the Security Plan.
Additionally, requirements for statutory and regulatory compliance may be imposed onto the organization, such as when they are stated as a part of a purchase order, contract, or other agreement.. Examples include: RoHS, REACH, DFAR, CUSMA, etc. The organization complies with any such requirements as needed.

Anything I could improve here? I'm under the impression that I should mention how exactly those requirements are addressed, but I don't want to get too prescriptive in the manual.
Let's start with the concept of a management system. This implies that all parts are working together for a common goal. Interpreting the requirements on an organization is what the management system needs to do. So, the need to integrated statutory and regulatory requirements into the system is what the is needed.

While the statutory and regulatory requirements may not impose requirements to the "QMS", they must be met by the organization.

If a new management team was put in place in your organization, would the document information (Quality Manual) ensure this new team would be aware of all of the requirements that impact the organization?

In the context of the organization section of the quality manual, a brief mention that the organization complies with all RoHs and REACH requirements would be a good addition.



Yes, this sounds good. I applaud the decision to use titles in the flow chart, as well.

There are companies that have a process called "Production", and the process owner is the "Manufacturing Manager". IMHO, that is where it really helps to define the process owner.

As a contrast, if the process owner has the title "Production Manager", it cannot be assumed that is the process owner, as it may be the 'Director of Finance" that is actually the process owner. So it is good when this is all documented and has Top Management consensus.
I'm a fan of rolling everything into as compact and readable form as possible, so it made sense to me to address who owns the processes directly in the flow chart. Good to know it works out.

The flow chart has a little note on the bottom stating that these titles are the identified process owners.
 
Last edited:
I should add, the way it is currently written into the manual is like this:

Scope of the system is stated above... The processes of our system have been documented in the Top-Level Process Chart. These describe inputs, outputs... responsibilities, and means of evaluation. Customer and applicable statutory and regulatory requirements are also addressed.

I'm not too sure which one would be a better fit for us. Its pretty vague as it is
 
I see. I could write this into our quality manual:
"The organization is registered with the Controlled Goods Program. The requirements relevant to GCP compliance are addressed, and can be found in the Security Plan.
Additionally, requirements for statutory and regulatory compliance may be imposed onto the organization, such as when they are stated as a part of a purchase order, contract, or other agreement.. Examples include: RoHS, REACH, DFAR, CUSMA, etc. The organization complies with any such requirements as needed.

Anything I could improve here? I'm under the impression that I should mention how exactly those requirements are addressed, but I don't want to get too prescriptive in the manual.
I wouldn't do that in the quality manual. Too many things change, so you want something easily changeable. I would put some boilerplate language in the manual if you have to. But I would use a simple matrix to identify what regulatory requirements you follow, and possibly include the reason why.

We follow the following regulation requirements where applicable:
REACH -- Customers A, B, C
RoHs -- Customer D
Dfars -- Customer A, where POs indicate said requirement

Etc.
 
Customer and applicable statutory and regulatory requirements are also addressed.
I like what you propose.

Consider too, under needs and expectations of relevant interested parties, it might be stated something like 'interested party - DDTC - needs and expectations - we maintain our registration for ITAR.'
 
We moved the stage 2 audit to late February.

I have a much better understanding of the requirements now, but still scrambling to pull everything together.

We are using color coded travelers and staff are generally learning the new procedures, which is good

Since I am simultaneously building the procedures, auditing my own work, and trying to train people, (and having to deal with confused or confrontational staff members) its proving to be pretty challenging. Especially since i am finding many nonconformities. I am in a constant dilemma. I could stop everything and simply do an internal audit, but due to time pressure and since i am the only one able to interpret the standard, any findings just come back to me, so it seems my best action is to just make decisions on my own.
The most major issue I noticed, is that information seems to ripple and lag through the organization, and im afraid i do not have the power to change that on my own

Management means well, and i am treated well, but are super limited in resources and are not able to be fully engaged in the qms development

Some days I wonder if i am biting off more than i can chew,

Having a good consultant would be incredibly useful, but due to budget and time we are most likely gonna have to ride this one out.

P.S @Randy it looks like he's worked with these standards:
QS 9000, M1003, ISO 13488, 14001, 9001, 13485, 16949, 18000, 22000
I hope your February audit was productive. I want to encourage you that I have been exactly where you are and the absolute best results come from you and your team taking that manual and changing it. The only value in the manual you got is hopefully a good structure. Other than that, you need an ally on the production team and a clear understanding of the difference between required and best-practice. There is a light at the end of the tunnel and it is not a train. After that, you hope and pray for auditors that will give you NC's so you get better and not to punish you. The NC's are your ticket to get management behind resolving them and in the process, making your system more robust.
 
I hope your February audit was productive. I want to encourage you that I have been exactly where you are and the absolute best results come from you and your team taking that manual and changing it. The only value in the manual you got is hopefully a good structure. Other than that, you need an ally on the production team and a clear understanding of the difference between required and best-practice. There is a light at the end of the tunnel and it is not a train. After that, you hope and pray for auditors that will give you NC's so you get better and not to punish you. The NC's are your ticket to get management behind resolving them and in the process, making your system more robust.
Thank you for your sentiments, it's much appreciated. I'm doing my best to stay on top of it, and to change things as we go to better fit our actual work process. I'm learning more and more as I go, and am starting to feel more comfortable giving guidance in regards to quality. Thankfully, all members of management are on board with this. They just don't often have the resources to be actively involved.

It's getting better though, and I think the prospect of getting aerospace clients is driving the value proposition in favour of really implementing a QMS that works.

It seems that the general sentiment towards these standards is that a working QMS is more of an art than a science. I'm excited to have the opportunity to be in this field, and I'm grateful for this forum and all of your input.

If you have any advice on working with management, conflict avoidance, how to get everyone on the same page, etc. it would be greatly appreciated.


As for the audit:

By a wild stroke of luck and some long hours, we passed the audit with 1 minor nonconformity.

Once we get the certificate in hand, I think we are due for a small celebration. (:
 
As for the audit:

By a wild stroke of luck and some long hours, we passed the audit with 1 minor nonconformity.
I'm glad you're getting your certificate! Hopefully, your management doesn't take this the wrong way and think you're done.
The good news is, you were in the audit and know exactly where you need to improve. I encourage you make a list (or Eisenhower Matrix), and present that to management so they know how much work is ahead. Otherwise, they may not give you the time to do it.

If you have any advice on working with management, conflict avoidance, how to get everyone on the same page, etc. it would be greatly appreciated.

First, some conflict (I say "push back") is good. Everyone has their end of the stick that they are responsible for, and they all have value and importance. Getting push back forces you to have a clear and compelling reason for what you want to do, at that is always good. Focus on defending requirements, not preferences (1. Customer Requirements, 2. Standard Requirements, 3. Company Requirements (Hint: these should align with customer requirements.)

"Preference conversations" are where you can focus on encouraging ideas and best ways of implementing requirements. Giving latitude in this area makes them feel like their voice is heard and valued.
 
Back
Top Bottom