ISO 9001 Scope - Exclusion of Design in an engineered solutions company

[normzone]

Your comment about the design process as you see it is on target.

Your organization IS doing design, they're just reluctant to acknowledge it for fear of having to add complexity to their system.

The good news is, the team is probably ALREADY doing what it needs to do to be compliant. Somebody just needs to map it out, figure out where what's going on aligns with the requirements of the standard, document the whole shebang, enforce it and audit it.

That sounds scarey but it's probably no more work than you're already doing, just done in such a manner that you can prove it's happening to anybody who cares.

And those other companies that are complaining about how meeting the requirements slow them down too much, and inhibit their flexibility? They're either whining because they would whine even if they had no requirements to meet, or somebody designed their systems to be cumbersome.

A well crafted system that meets the requirements of the standard is far more reliable than a poorly crafted variant, and no more work.

Consider this a challenge, and get cracking. Make it your goal to meet the standard by refining your existing system - work with the people involved to make it efficient and effective while adding the absolute bare minimum of burden.

 

[Ithalion]

Two fundamental questions may be asked to determine the answer:

Who authorizes changes to product specifications?
What 's the wording of your customers' agreement/contracts with you?

Currently, authorization for small to medium sized things comes from the Design Engineer, but with bigger things, it also needs the approval of the Manager of Operations (which I realize probably needs to be defined/formalized).

I'm not sure exactly what you're talking about for the "wording" you're asking about, but basically we quote them (which includes Terms & Conditions), then they send a PO, then we acknowledge it. None of it really mentions design though. But basically how it works is we have full authorization for all design change in most cases (though not always, some bigger jobs our engineers design in collaboration with the customer), though we will inform and consult the customer if it's a major change. Is that what you're asking about?

 

[AndyN]

Currently, authorization for small to medium sized things comes from the Design Engineer, but with bigger things, it also needs the approval of the Manager of Operations (which I realize probably needs to be defined/formalized).

I'm not sure exactly what you're talking about for the "wording" you're asking about, but basically we quote them (which includes Terms & Conditions), then they send a PO, then we acknowledge it. None of it really mentions design though. But basically how it works is we have full authorization for all design change in most cases (though not always, some bigger jobs our engineers design in collaboration with the customer), though we will inform and consult the customer if it's a major change. Is that what you're asking about?

OK then you are design responsible!

 

[Big Jim]

Thanks; the reason they don't want to include it is because many of our customers are bigger companies that have ISO and it drastically decreases their speed and flexibility of Design apparently -- I guess those companies just aren't using ISO right in that case, but that's the examples my Top Management has seen.

I will definitely bring this up with my potential CB though.

Anyway, anybody have any comments on the first part of my comment about the Design plan?

If ISO 9001 is slowing them down, they aren't doing it right. Done right, ISO 9001 makes life easier, not harder.

 

[AndyN]

If ISO 9001 is slowing them down, they aren't doing it right. Done right, ISO 9001 makes life easier, not harder.

Never was a truer word written - however - the down side is "hidden" in an engineering function, because the need for processing design changes is taken to be "natural" and a normal function of design engineering. Sadly, it's usually no more than a pile of rejected product awaiting "rework". When you categorize design changes into "paid for by customer" and "paid for by us", you soon see it's not ISO slowing things down...

 

[Paul Simpson]

<snip> I work for an engineered solutions company that manufactures mostly control panels. Now, based on that statement, I know it will sound absurd to ask if I would be able to exclude Design, but here's my reasoning. First off, I'm not certain that what we do would be considered design, because we are not doing R&D type work of developing new products; we are given specs from customers which one engineer then sits down and "customizes." Our customers have a varying degree of knowledge of the technical side of what they want, so one customer might say "we want a panel that can do XYZ, now you figure out what that needs" and then there's some customers that say "We want THIS drive, THESE terminal blocks, THIS colored pilot light". The thing is, even for the first case, they're all still control panels, we're just customizing what goes on it and where, we're not designing a whole new product line or anything. Maybe that is blatantly design, but I'm hoping there's a difference. :</snip>

It would help to know a bit more about what these control panels do.

The way I read it you are on track and you are doing applications engineering. A customer comes to you with a list of measurements it wants displayed on a display unit and you produce a unit that gives them the capability they want through a process where you select measurement modules and arrange them in a panel.

I'm with you. If there is no original thought in the process (and that isn't to demean what you do, my guess is you are very good at it) then it doesn't require the formalized verification / validation / review you refer to.

<snip>Regardless, we didn't want to even include Design in our Scope, because honestly, we think we can get what we want from ISO 9001 without including it, and we can't think of a way in which it wouldn't be a massive headache for most Jobs we do. Here's why:

Our company is a customization company based on EVER-CHANGING customer specifications (even long into the manufacturing stage), so having to set up a Plan (7.3.1) and add inputs that would just be constantly changed seems rather pointless. There is an unbelievable amount of change during the process based on dynamic customer desires, realizations of a lack of feasibility for certain layouts from the manufacturing technicians, and so on. Basically, it's a process that constantly gets new inputs (that can't be foreseen at the beginning), all the way up and through the testing of the product, from the customer, engineer, and builder.

Now here's the rub.

Even if you don't have a 'Design' process you will still have to demonstrate control over the 'ever-changing' needs. Your customer related processes have to be a lot more comprehensive than the normal 'receive the order, feed the factory' process. All the to-ing and fro-ing you describe has to be captured and tracked to ensure that what goes to manufacture has been agreed with the customer and reviewed for suitability for your production capability.

You've touched on some key points like responsibility, feasibility assessment and change control and your 'Sales Order process' is going to look a lot like a design control cum production planning process soon enough.

Call it design, configuration, customisation or whatever you want to - it is a process which requires control. Clause 7.3 is probably the most detailed of all the clauses, it gives you a structure (is you wish to adopt it) to work to with 7 neat sub-sections - just follow the path provided and you have a well controlled process. It doesn't have to be difficult.

You mention having a plan would make you less efficient, are you saying that you don't already plan? or that you don't have a separate form which is called a design plan and is created for each design, because the clause doesn't call for that. It could be a generic plan.

Agree with Colin that design control doesn't have to be difficult, it is a planning activity followed by simple stage gate sign off - like musical notes on a score. Like in music, the clever bit is in the gaps in between the notes!

So, just confirming what you're saying here, I can just make a generic/broad form for 7.3.1 that applies to all Jobs (rather than a new one for each Job)? Then just maintain the records of 7.3.2-7 for each Job? For example:

Responsibilites:
1. Aquire Inputs: Design Engineer & Sales
2. Design: Design Engineer & Drafting (and sometimes Customer)
3. Design Review & Verification: Manager of Operations and Operations Manager (and sometimes Customer)
4. Manufacturing: Operations Manager
5. Test (Manufacturing Review, Verification, & Validation): Operations Manager, Test Technician (sometimes Design Engineer & Customer)
6. Maintain Records: Design Engineer

Stages:
Stage 1: Aquire Inputs (PO)
Stage 2: Design (Create BOM & Draft Drawings)
- Review and Verify
Stage 3: Manufacture
Stage 4: Test
- Review, Verify, Validate


Secondly, so it seems what my company does is DEFINITELY design, and the vibe I've gotten is that yes, I CANNOT exclude design. I'm NOT talking about whether it's a good idea or not to exclude it (I've taken your opinions into account and I appreciate them), but whether or not I HAVE to include design. I have read elsewhere in this forum that even if you do design, you do NOT have to include it in your scope if you don't want to, merely that it would be foolish not to do so (as long as you make it clear that your certification does not include Design) or that you can even consider it an outsourced process if you want to exclude it? Again, I'm looking for what is ALLOWED technically, not the wiseness of one course over another; I already know the majority of this forum's stance on that

(The reason I don't seem to care if it is wise or not to exclude design is because I may not be able to convince Top Management that ISO is for us if we have to include design...)

The good news is that with the 2015 edition exclusions are history and you have to make a positive scope statement. This gets over the debate - except when your auditor arrives and starts assessing you to the design requirements.

Your pitch to top management is of the benefit of control and it sounds like they have had their fingers burned with design control. It might be good to get some idea of the history and prepare some argumnets based on the replies in this thread.

Oh and feel free to share the horror stories here!

 

[Sidney Vianna]

If ISO 9001 is slowing them down, they aren't doing it right. Done right, ISO 9001 makes life easier, not harder.

Imagine that you are responding to a COMPLEX Request for Proposal which references numerous national and international standards, industry codes, etc... ISO 9001 requires you to review the RFP requirements and ascertain that your product/delivery can comply with all of them or you take exception and get the customer to agree with the waiver. Performing a thorough review of all the documents referenced in the RFP will certainly slow you down, but, in exchange, provide you and the customer with the assurance that no bad surprises will happen later on.

Some organizations do lip service to thorough review and understanding of the technical requirements involved with the RFP and return a proposal, taking significant risks for the lack of an effective review.

So, complying with the intent and requirements of ISO 9001 does not ALWAYS make the organization life easier, but it "forces" them to do the right thing and manage the risks appropriately.

I could give many other examples where ISO 9001 would make the life of the organization much more disciplined (which some people would equate with harder), but certainly not easier.

 

[Big Jim]

Imagine that you are responding to a COMPLEX Request for Proposal which references numerous national and international standards, industry codes, etc... ISO 9001 requires you to review the RFP requirements and ascertain that your product/delivery can comply with all of them or you take exception and get the customer to agree with the waiver. Performing a thorough review of all the documents referenced in the RFP will certainly slow you down, but, in exchange, provide you and the customer with the assurance that no bad surprises will happen later on.

Some organizations do lip service to thorough review and understanding of the technical requirements involved with the RFP and return a proposal, taking significant risks for the lack of an effective review.

So, complying with the intent and requirements of ISO 9001 does not ALWAYS make the organization life easier, but it "forces" them to do the right thing and manage the risks appropriately.

I could give many other examples where ISO 9001 would make the life of the organization much more disciplined (which some people would equate with harder), but certainly not easier.

I understand your perspective, however, life is still much easier with the discipline you mention than living with the aftermath when you are not disciplined. MUCH easier.

 

[AndyN]

Imagine that you are responding to a COMPLEX Request for Proposal which references numerous national and international standards, industry codes, etc...

My experience tells me that this isn't a significant proportion of organizations. Those which design their own products (innovation) rarely see complex RFQs. The organization's products and specs are what people buy, without stating the customer bringing their own requirements. At a previous employer, our designed were world leading - significant customers simply bought "1,000 x Product X" (typically).

 

[Johnson]

From your descrpition it is a risk to say you can exclude clause 7.3.
Another consideration is to look at your organization chart, it you have department containing "Design","Development", "Engineering" , you may not be able to prove you are free of design responsibility.
I don't think the requirements of 7.3 is difficulty to meet. It only has requiremements like input, output , review, validation, verification etc, but it does not define how do do it. If you have only simple "design " function, then you can simply the process and documentation. If some requirement of ISO9001 was considered as a burden or useless, it may indicate it is not understood the reall meaning of the requirements.