New revision vs new partnumber

That works for a by-glance comparison of nominal geometry, but not tolerance variations and other engineering analysis needs to validate that the new part is sufficiently interchangeable if it is changed in some non-trivial way.

x

Hi David,

I was working with our checker with CreoView MCAD compare. It does work with drawing dimensionsand GD&T features when appearing on drawing views. Are you only using 3D model comparisons or 3D drawings? I haven't tried the 3D drawings yet. I'll take a look when I get the time.

Patrick

In Reply to David Schenken:

That works for a by-glance comparison of nominal geometry, but not tolerance variations and other engineering analysis needs to validate that the new part is sufficiently interchangeable if it is changed in some non-trivial way.

x

I'm refering to the way the next assembly functions with different versions of multiple copies of the same part, not the documentation for the part itself.Example:replace one sparkplug in a car engine with a new version and see if the motor runs rough because the spark ignites fuelearlier or later on the new plugthan the remaining old version spark plugs.

It's one thing to verify interchangeability when an item is replaced in its entirety, which Pro/E can deal with. It is another when the item, because it the same part, but different versions, which Pro/E can't deal with. This is the advantage of multiple part numbers - any part can be installed at any time, without regard to the presence of other parts. If only using revision one is restricted to only having one version available at a time.

As to Creo View, it can view the drawing and a static picture of the model, but it can't show what the model is like at dimensional tolerance limits. If those limits are revised, but not the nominals, it is possible the new part will not function the same as the old one and there is no analytical method in Creo View to tell that that is the case and what the result might be.

x

I believe in Revisions control and not new part numbers as the general rule.

But it boils down to how you do business, what type of products you make, how are they packaged together, etc.

A company must always do what make the most sense for thier particular situation.

We easily manage our product designs with revisions and never create new part numbers for design changes. There are rare cases where we may do this, but it must be approved by a comittee in order for it to happen.

Olaf mentioned all the great benefits of revision history so I won't repeat them here. If your product line is difficult to manage with revisions, then you must make adjustments that make sense for your company.

I think you should always control designs by revision, unless it's not possible. In that case you need to do what works for your company and just make sure there is no confusion about it. As long as everyone is in agreement with your process and there is no confusion, anything CAN work.

ΜΟΛΩΝ ΛΑΒΕ

Hi NacNac MOTT,

Here's another question guys who believes the CAD files represents the actual materials. You mentioned that you place family tables for material changes and not fit changes. How far does CAD go to manage all the "non-3D" attributes of a material?
Should it be placed in the Windchill material/Part object? If not,can the CAD file become a generic 3D feature based object that can be used anywhere. We talk about proliferating CAD files or information. My hope in the future is that 3D CAD files are just 3D CAD files and the metadata of the information is kept in another object. I would love to keep information in its small sets where it can be reused and reassembled to generate unique object. Why not place this information in PartsLink Classification?

Many reasons to revising a CAD file after officially released beyond fit, form, function changes:

• Sometimes in CAD there is so many inter-object relationships and dependency that it is a package of files


• small changes in the CAD file like a layer, adding a datums, etc

The funny thing about communication with vendors and other departments intrusting in what you changed after release. Most cases, they usually want a new revision of files no matter what becase there was a different in the files you sent them.

I took a look at your product definition slide. I'm more accustomed to looking at a product definition like a 4 sided piramid. each side covers:

• Marketing and Customer structures with requirements


• Design structure with changing revisions


• manufacturing and service structure with changing revisions and different plants/lines and effectivity


• purchasing and supply chain structure with changing revisions to the manufacturing

Each side you can draw multiple lines from the apex down to the bottom generating a specific baseline of information. The middle volume base is all the documentation with its own revision control.

That's my view of the business solution regardless of tools.

Having fun as always,

Patrick

In Reply to NacNac MOTT:

Hello guys.

Hopefully I am hopening pandora's box 🙂

I guess there are only two schools.

One who never revise and systematically create a new partnumber

Another who always try to revise (but if the change impact various product differently then they may "split" the design and create a new partnumber)

I am from the second school. If after the impact analysis all the impact references can accept the change, then a new revision is created. If, for sake of argument, a part is used in 100 assemblies, and for 20 of them we cannot accept the change of the part, then we create a new part. Then depending on the effort, the new part will be used in the 20 assemblies while the other 80 will get the new revision of the original parts.

I really do not understand the first school. It requires a lot more efforts. Of course when you do not have CAD (understanding 3D cad), it is relatively easy to mass BOMs, but as soon as you have to update 3D cad, this can become very complicated.

In addition, you lose the history of the part.

One of the reasons of the First school is that if after the change the part is not 100% interchangeable, it should be a different partnumber because of the risk to mix it in the warehouse for instance. My argument saying that well, when you work you should work with partnumber AND revision, but this would mean working with revision level in ERP too. Then I put forward the argument that any change as an effectivity date. So Revision B is valid up to Day whatever, and from that date you use Revision C. The Day D, depends and may vary depending on how fast you can clear your stock of revision B.

What is your views. Are you from the first school or second school but most importantly what are your argument to belong to one school inparticular (or maybe there is a third one)

Thanks

Hi Nacnac,

Maybe I can still add something to this thread.

Since the discussion highly depends on the business you are in: we are not in the military business, nor in aviation, nor in nuclear, we develop, make, sell and service highly complex industrial equipment, involving mechanics, electronics and software.

1/

I think you have to consider where you are in the process of your component, and what you want to
achieve. Our machines can be 20 years old and more, we have to provide service for very old machines. So, the investigation of backward compatibility (BC) is of extreme importance for us. But BC depends on the 'where used' of the
component. The same component can be 100% compatible in one BOM, partially compatible in another, and not compatible
at all in a third BOM. I don't know if revising your component will help you to model this complexity? I have no experience with 'substitutes and alternates' in Windchill, I think and hope it's meant to tackle this.

2/

On the beginning of the life cycle of a design, in Creo, we recommend our designers to always revise CADdocuments, unless the older revision is kept alive parallel to the newer revision for a longer time, and it's likely it will change in parallel. This way, we try to keep the top-down reference structure in Creo intact, preserving the design intent of the
machine. When you make copies of CADdocuments, because the change is not form-fit-function, the new CADpart will replace the old CADpart in its CADassembly, so jeopardizing the design intent. That's something we want to avoid by all means.

But our designers have learned to associate a new part (with new revision) to the newly revised CADdocument. This way, we use the association between CAD and WTParts as mapping table between CAD and ERP. Of course, this is only possible if you avoid naming your CADdocuments according the WTParts.

3/

What exactly are you going to revise? Only the component (WTPart), or always all the CADdocuments along with the WTPart? A daughter company in the group chose not to release drawings, only to release CADcomponents and WTParts. Hence, they don't need revisions on drawings. Of course, they make use of the iteration history of the drawings. But they are fine with it.

At our site, on the other hand, we are considering to allow changes without revisions, just a simple 'set state' and off you go. Although there is the iteration history as well, and basically, revisions and release procedures are meant to trigger actions in the organisation, I'm not in favor of that approach.

4/

When you change a component, what do you do with the upper level components? Suppose, there are 12 first level
where-used's, 5 of them are not used anymore, 7 of them are. Those 5 will be left behind, I think, but those 7 all have several upper level components as well 😞

Our approach is to propagate the change up to the level where components are stored in an in house warehouses. New numbers always get own locations in the warehouse, I suppose numbers with revisions will be treated the
same.

5/

In contrast with PLM, you can say ERP-systems are around since ~30 years, and have reached a fairly status of functional maturity. As mentioned before in this thread, SAP is not built to cope with revisions. We are trying to get up to speed with AX, but revisions are also for AX not the strongest point. Maybe PLM and ERP should be tied together intimately, leaving the revisions for PLM.

But is this an option? Are there examples for such an implementation? The main problem I see is that ERP should be able to schedule both revisions, to phase in and phase out the new and old component.

Some thoughts, Hugo.

<< ProE WF5 - PDMLink 10.1 M040>>

Hi guys,

Let me talk about my idea. Maybe many people have talked about my idea too but let me just say something from my side.

When we make a change to a part, it brings impact to both PLM and ERP, or in another word, both engineering and supply chain (manufacturing included). 

To reduce complexity, personally I prefer to revise and not to create a new part number, if possible. 

And, I believe that if you have made a change to a child part, all the parent assemblies (2D+3D) that are using this child part and have accepted this change must be revised too, and the new version can be implemented together in one Change Notice. Only when some parent assemblies do not accept the change or the old design brings very severe risks should we create a new part number. 

If we revise, benefits are:

1. In PLM, We have the history of the part: what does it look like before? Why did we need a new version, what is the background, who made this change, how the change was implemented? 

2. In ERP, we have all the existing master data and we do not need multiple related functions to maintain the data again. 

The risk is:

1. In engineering, have we done a good impact analysis? Will it really fit all parent parts?

2. In ERP, how does supply chain and manufacturing control the version change? 

But I believe we have ways to control the risks.