Community Tip - New to the community? Learn how to post a question and get help from PTC and industry experts! X
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>>