cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

Community Tip - Visit the PTCooler (the community lounge) to get to know your fellow community members and check out some of Dale's Friday Humor posts! X

Definition of FFF changes

ocorten-2
9-Granite

Definition of FFF changes

About Form-Fit-Function changes leading to new numbers instead of a new revision.
What kind of changes does your company see as FFF changes?

I have had many discussions with ERP guys about this.
Some are extreme rigid: any Form, Fit or Function change should result in a new number.
In our company this would relate to about 90% of the changes being FFF changes. Which again would be a downstream nightmare.

What about these changes:material change
could result in improved functionality (better strength)rounds added to remove sharp edges
Form changedchamfers added to better aid assembly
Form changedholes added to be able to screw on new functionality
Form changed, Functionality addedmaterial has been removed to make the part cheaper
Form changedmaterial has been removed to make way for additional functionality
Form changed, Functionality addedribs added to strengthen the part
Form changed, Functionality improvedreleased revision has a fault.
Form and/or Function must be changed old revision must be replaced or reworked.
But should all these FFF changes result in a new number instead of a new revision?


One of the topics in these discusions was always about interchangeabilty.
If the revision is interchangeable then a new rev is allowed.
But what does that exactly mean?
Should the new revision be interchangeable:upwards and downwards
new rev can replace the old rev and old rev can replace the new rev.only downwards
new rev can replace old rev, but old rev cannot replace new rev

Another discusion topic was about traceabilty.
Revisions are much harder to trace downstream than new numbers.
So if you want traceability you must change through a new number.
The magic word here is effectivity.
With effectivity (date/lot/series) you add another dimension to your revisions.
This helps greatly in managing bom's and revisions.
No longer you need to revise all the way up the tree. Just specify the effectivy of the tree you want to browse through.
But how many companies are "effectively" using effectivity today?



Kind regards,

Olaf Corten




Olaf Corten | CAD/PLM Manager

Besi Netherlands B.V. | Ratio 6| 6921RW Duiven| The Netherlands
T: +31 26 3196215 | M: +31 644548554
- | www.besi.com

Confidentiality Notice:
This Email, and any attachments, may contain internal or confidential information and is intended solely for the individual to whom it is addressed. It may contain sensitive or protectively marked material and should be handled accordingly. If this Email has been misdirected, please notify the author immediately. If you are not the intended recipient you must not disclose, distribute, copy, print or rely on any of the information contained in it or attached, and all copies must be deleted immediately.
6 REPLIES 6

Generally the definition I've come across as a few different companies involves the question "Is the new revision backward compatible all the way back to the initial release part?"

In practical terms, this means that Revision T could be used in place of Revision - (initial release) and the end user/customer would not have any problems. Any other changes done should be okay as part of a revision rather than as a new number.

As for your specific instances, I'd have to go with... (answers in red)

* material change Negative
could result in improved functionality (better strength)
* rounds added to remove sharp edges Negative
Form changed
* chamfers added to better aid assembly Negative
Form changed
* holes added to be able to screw on new functionality Possibly (depends on how the backward compatibility is affected)
Form changed, Functionality added
* material has been removed to make the part cheaper Possibly (depends on how the backward compatibility is affected)
Form changed
* material has been removed to make way for additional functionality Possibly (depends on how the backward compatibility is affected)
Form changed, Functionality added
* ribs added to strengthen the part Possibly (depends on how the backward compatibility is affected)
Form changed, Functionality improved
* released revision has a fault. Possibly (depends on the situation)
Form and/or Function must be changed old revision must be replaced or reworked.
This last one may be too broad depending upon the situation and the level of fault. A faulty part would have to be evaluated whether to leave it in the field (knowing customers may be affected), issue a bulletin giving customer the ability to receive and replace themselves, recall it, or (if it's still in-house) scrap it.

sjohnson-3
4-Participant
(To:ocorten-2)

Well written!

It's very interesting how so many organizations have a different take on what warrants a revision versus a new part #. With our company it is all about downwards only interchangeability. We always ask ourselves, "if a part or portion of any product needs to be serviced, will the proposed change effectively swap out and maintain all end use functionality of all previous revisions?" If yes then revision, if no then new part #(s). The key is end use functionality, which is dependent on the part(s) application (fit, aesthetics, ...). If a new revision then all previous revision parts can then be co-mingled and consumed, or if it is a faulty revision per the last FFF example below they would be reworked or disposed of.

Our current shortcoming now is effectivity of a change. An example of this being an issue would be if a released revision was later found to have a fatal flaw that needs immediate replacement. On which orders do we process the recall? We don't have a firm handle on this yet, though thankfully up to this point this has not proven to be a problem for us.

Sometimes it can be tough, as we are always calculating in the backs of our minds the time/trouble we will be up against in our CAD/PLM/ERP system dependent on the proper course of action, but ultimately it is a real world feet on the shop floor & hands on the product decision.


Sasha Johnson
Sr. Design Engineer
[Description: cid:image003.jpg@01CB6B8D.783AA0A0]
Russ Bassett Corporation
8189 Byron Road
Whittier, CA 90606
Phone 800-350-2445 X 3345
Fax 562-447-2228
sjohnson@russbassett.com<">mailto:tsimon@russbassett.com>
www.russbassett.com

Hey Olaf,


We have been discussing these as well in the context of our future ERP integration:


Change ...


The designer has to consider whether his changed part or assembly will be backward compatible in all (relevant) where-useds. I.o.w. the modified article must be useable everywhere where it's used now (so one direction). Else, it's not a revision, it's a new article.


When the action in the organisation is only the phase-out/phase-in of the changed specs, we agreed to only raise the revision of the drawing, not of the article. Hence, we will not be able to decide which machines will get which revision. Most of the changes are of this type. Since the article doesn't change, the impact in ERP is minimal.


Since ERP doesn't fixate and remember all revisions of all articles all the way down in the BOM, we have to escalate the revisions up in the BOM high enough in case we think it will be necessary to trace it back.


So, we think it's important ...


... to have revisions on articles, even when there is no drawing for that article


But I'm talking about a (near) future ERP-integration, and the ERP-team is convinced to introduce revisions on articles in ERP, we are all curious about the real live scale effect of those theoretical concepts. To be honest, I would feel more comfortable if someone could come forward with practical experience with revisions on articles in ERP.


Regards, Hugo.


Since 2002 we have been running with Windchill tightly integrated to ERP, the only way to get a new “article/item/part/material” (use appropriate term depending on who you are talking to) in ERP is to create a WTPart and release it in Windchill. This integration also passes a lot of metadata, including version/revision and the Engineering BOM. This BOM is then controlled in ERP so that it has to be used as is and can be augmented at the location/branch level. In practice this means that the branch BOM is a level deeper than the Engineering BOM as it will include raw material and other consumables not shown on the Engineering BOM. We rely entirely on our Windchill managed Engineering Change process to automatically communicate the revision throughout the business, we have a closed loop ECN interaction with ERP to make sure this happens. We do not use Effectivity and are always build to latest Revision.


In regards to the Fit Form Function discussion, we have the policy (it is written down but cannot be system enforced) that any physical change to an item, or its BOM, as far as Windchill is concerned requires a revision. If the new revision will no longer be universally interchangeable with the earlier versions then it must be a new part number and the assemblies must be revised to swap out the components.


So if you need to edit something in CAD to modify or add a feature, or you are changing a dimension, or the material, or a surface finish, tolerance or coating, etcetera. Then you should be revising the WTPart and linked Documents to communicate that, same applies if you are editing the BOM in Windchill. If the changes you need to make do not modify the physical part or BOM then you do not need to revise it. Examples would be things like fixing spelling mistakes, adding a missing dimension or re-arranging a drawing to make it easier to read. We have an “I1” (iterate or informational) category of Engineering change to facilitate users making edits to released data without revising it. Due to our automated closed loop process on Revisions, they generate a lot of activity throughout the enterprise. We don’t want to trigger all that unnecessarily, so an I1 change is an efficient alternative for trivial corrections, clearly it is somewhat open to abuse though particularly if you have approver who just rubber stamps every change that comes across their work list.


All that said, the FFF change and new part requirement is only necessary when there is affected Assemblies/Inventory/Assets or Open Orders for those. So if the business has only built one of something, has no orders for any others, and an issue is found in assembly. Then it is acceptable to revise a component (not used in any other assemblies) and make edits to it that mean it would not be interchangeable with the earlier version. This is acceptable in this case because there is no impact to any other assemblies/inventory/orders. Clearly depending on how sweeping a change is being made and how much activity is involved in making it happen, there are various shades of grey between my black and white examples that are workable with sufficient engagement between Engineering and the rest of the business.


On all our manufactured parts there is a requirement that says something like “Mark Part No and Work Order number in this area”. The Work Order is the system of record in ERP for the production of this item, it gives the full traceability for an item from Raw Material through to final inspection. We also use full serialisation and Lot Control (which can be thought of as group serialisation) in some plants, but that is not really relevant to the discussion above.



-----

Lewis

Hi Lewis,


1/


Do I understand you correct, that your ERP system works with versioned articles as well? Do you keep article-versions in your inventory bins on the shopfloor? Reading http://www.buyplm.com/plm-good-practice/plm-software-part-revision-form-fit-function.aspxand other blogs disadvises strongly to have revisions on articles in ERP. But I don't agree, as long as you consider the revision of the article as part of the identity of the article. So, you always have to communicatie and manage 'article-versions'.


2/


Do you have articles without a drawing, and do you have revisions on those articles? E.g. because of a BOM that changes? Until now, we have a lot of articles without drawings, with BOM's that change frequently. Wehave the idea to introduce change management on BOM's as well.


3/


Who decides on the FFF? The designer alone, or in collaboration? We are working on a workflow where the designer passes his drawings and other specifications including the BOM-proposal to Order Processing, and Order Processing decides what it is going to be.


Thanks for the input, Hugo.


<< ProE WF5 - PDMLink 10.1 M040>>

In answer to your questions:


1) We do pass a version over to ERP but we don’t maintain history of versions there or use any of the functionality around Versions in ERP, the version history is maintained in Windchill. In the most part (might be one or two exceptions by product line) we do not mark the version on the part itself. So effectively the version is an attribute that is added to the Work Order to give traceability, this means that the version is recorded on the Work Order as it is executed.


2) Everything in ERP has a version, whether it has supporting documentation or not. In my opinion you have to be using WTParts and use the version on those as the control point. There could be valid reasons for revising a document without revising the WTPart (changing the drawing format for example, or swapping to a different newer drawing entirely). Additionally there may be more than one document required to manufacture a given part. There is no value in having the document versions in ERP or trying to keep all the Windchill object versions synchronized. Far better to have a policy like “You view the required WTPart version in Windchill and whatever documents are linked to that are the ones you have to use for production”. The WTPart to ERP record should always be 1:1, by having the “current” Released version available in ERP you can have a solid tie back to a particular Windchill WTPart version from the Work Order while it is in execution. From a given WTPart version you get to the required documentation (and versions of that), this gives full traceability at audit time without having to use any clunky ERP functionality around versions and document numbers.


3) The decision as to whether a part must be replaced or if it can be revised is at the discretion of the Engineering group responsible for it, the decision is actually made by someone in Engineering and approved by their manager during the ECN process. Some Product Lines have a Change Review Board type meeting with their supply chain, others don’t, it really depends on the nature of the product and how diverse their supply chain is. The only time this causes issues is where you have two separate “sister” products that share some Engineered componentry, this may lead to a bit of a turf war over who owns what.


-----

Lewis

In Reply to Hugo Hermans:



Hi Lewis,


1/


Do I understand you correct, that your ERP system works with versioned articles as well? Do you keep article-versions in your inventory bins on the shopfloor? Reading http://www.buyplm.com/plm-good-practice/plm-software-part-revision-form-fit-function.aspxand other blogs disadvises strongly to have revisions on articles in ERP. But I don't agree, as long as you consider the revision of the article as part of the identity of the article. So, you always have to communicatie and manage 'article-versions'.


2/


Do you have articles without a drawing, and do you have revisions on those articles? E.g. because of a BOM that changes? Until now, we have a lot of articles without drawings, with BOM's that change frequently. Wehave the idea to introduce change management on BOM's as well.


3/


Who decides on the FFF? The designer alone, or in collaboration? We are working on a workflow where the designer passes his drawings and other specifications including the BOM-proposal to Order Processing, and Order Processing decides what it is going to be.


Thanks for the input, Hugo.


<< ProE WF5 - PDMLink 10.1 M040>>









Top Tags