How to interpret and structure "major.minor"

[SG_14118493]

Hi Gents. 
I have seen this same issue as this topic: Using Major/Minor revisions - PTC Community, - how to interpret and structure "major.minor", as R&D Lead in several organisations. (Defence, Oil & Gas, Consumer Electronics), and have found this thread while trying to understand what windchill implements as standard.

My take is this: Lets choose to interpret minor change as No NEGATIVE Impact on "FFF" **at the level of the item in question** AND NO change required to any production documentation, test procedures or impact on requirements.
Major change is the converse of this.

Rationale. In engineering assemblies, as long as the change we make on our part/assembly still meets the requirement on it with **at least** the same margins, AND impacts nothing else (as above) then it is **fully compatible**. It is a minor revision. The fact it may have improved something, is for the product manager to take advantage of at a higher BOM level when that becomes relevant for sales.

This makes it easy for the individual engineer to make a Yes/No judgement on whether it is a Minor change, based on the immediate usage of that part, in its place in the assembly.

Where the primary BOM management is in PLM, the ERP does not need to have all the change traceability. So now, PLM can handle major/minor notation with its standard fields.
For production, what you can do is concatenate the Part number and major revision into the ERP Part Number.. its a new part number !!
You put the minor revision in the ERP Revision field. (ERP's usually have only one rev. field)
With this method, you satisfy ERP and production use of Part Identification.. they get a new Part Number when there is an incompatible change, and a minor revision when a change on a part is fully compatible with current assembly instructions, and test procedures.

But what we have done, is preserved the full revision reference between design and production (ERP) domains.

I have seen this done between ARAS innovator and SAP, and I am now writing it up for my organisation to use with Windchill.

A variant on this, as someone has suggested here, is to use a separate "impact" revision number. I also think this is worth considering.
Advantages over traditional major-minor
1.   A change results in a single revision step, regardless.

2.  The designer is asked by PLM to specify only whether they **believe** at the time of design that this will be fully compatible, and PLM increments the separate Impact field from say 2, to 3 for that revision.

3.  The act of making the change is logged, and may even need to be released for production in order to test samples, but now if the impact is seen in test to be compatible or not, against what the engineer originally thought, then the impact number can be re-assessed and changed.

4. The Mapping would remain the same. Part Number Concatenated with Impact Number to ERP Part Number, and the PLM revision field to ERP revision field. The result is the same. New Part Number for non compatible items which therefore need a separate production BIN. 

Cheers,

Stephen

[avillanueva]

I think you are adding extra business logic that shifts problem somewhere else. It might end up making things more complex. Take for example the question of next revision. The simple act of revise where Windchill looks at the series and chooses the next available letter or number in the sequence becomes custom logic and a user decision point. Do I increment the minor portion or the major portion, resetting the minor in response? All places in the system would need to be updated to implement this.

Next there is configuration specifications. Following normal rules, if these are all treated like revisions, when I ask for latest of a part structure, the latest major.minor revision applies and appears. But by the definition of a major change, it is not respecting interchangability when FFF mattered. Take the the simple example of an assembly and a component that undergoes a major change and the assembly response at its level with a minor change (change impact should dissepate as you move up a structure). If I looked in the history at the prior revision of that assembly with latest config spec, it will show the latest of that component, the latest major revision which by definition is FFF incompatible. You would need to address these in your solution which will eventually lead you to having to be revision specific at every instance of adding a component. 

Finally, there is your transfer to ERP system. You now have custom logic added outside both system (via transfer concatentation) that part 12345 A.1 equals part 12345A rev 1 in the ERP systems. Every single extract, comparison, translation or reference between the two system needs to enforce this new rule along with the users when looking things up. I have seen this early in my time at my current company with one program and it was a nightmare, quickly abandoned. 

The alternative is how things are now, simpler. Part number in one system equals part number in another. By enforcing FFF rules and number changes on PLM side, both sides agree internally and at rest. When we look up BOM structure, we can clearly see those major changes as part number changes, where they applied in history and it ensures that we cannot generate incompatible structures.  When a user needs to revise, rules are simple, next letter please. 

An alternative I have seen to support major/minor revisions seems to address  the magnitude of change impact. FFF rules still apply but you can accomodate changes like simple typos and inconsequential administrative cleanup, truely no impact. If you business process allows for this, you can simply iterate without revising. You need to clearly document the cases for this and which set of limited people can do this. You can also let revisions occur always but make the turn around process very quick. Minimal change documention, simplifed workflows and few sign-offs (fast fast track). Often when I see proposals for complex revision sequences, its the trap of "...then you'll know..." and the real issue issue is, "that process is too hard to follow, let's make an easier side path". 

[SG_14118493]

Hi. 
Thanks for your reply.

The very last paragraph you wrote is the correct solution for sure .. major minor revisions, and the fields used exactly the same in PLM and ERP .. SAP in our case.

but it's also where the problems I am trying so solve originate.

SAP has as default one revision field only, and it's only 2 characters long.

We need to differentiate between major and minor, the lack of it is causing all sorts of work arounds in every corner, .. routing on the shop floor, coloured labels to indicate part batches which are compatible and which are not.

In Electronic CAD it's a major change to change the part number for every major step,, and the tools don't support it. So it's not LEAN for them.

Even with windchill, I have asked what standard major minor schemes they have, and am told this is always a custom implementation.

So you can see maybe that while my suggestions are a compromise from the ideal, I and trying to get something done when Our ERP management have forbidden more than single revision field of 2 characters, and won't budge.

we want an interface to automate data transfer to SAP .. so resolving this is essential.

[avillanueva]

Ahh, I too use SAP and know of the restriction you are dealing with. Yes, that is an immovable stone getting SAP to change. But let's step back and understand why it is only two characters.  This allows for 100 numeric or 676 alpha revisions. That is more than enough to support true revision changes.  So they are backing in some best practices.  Introducing even the period separator makes it fall apart. 

I strongly would recommend the following. Ditch the major.minor. Let a revision be a revision and do nto care if its big or little. Do not confuse major with FFF changes where part number must change.  But, if you handle the impact of any revision change at the change object level (some documentation impact or no impact), things will flow better. Yes, you folks will have to read those and not assume revisions have no impact but overall system will be easy. 

Keeping a complex major.minor will force you too a file based series I think and a manual controlled revision process (would need to have a workflow step for a key user to make these calls). Mapping to SAP would see you split the revision and put the minor in the rev field of SAP and tack the major to the part number but essentially what you are doing is changing the part number. This should only be done with FFF changes.  And we find ourselves back at the top again.  

Curious when you say that electronic CAD does not support changing part number? Are these circuit design tools? 

[SG_14118493]

Hi.

For PCB cad, the part number is typically etched in the PCB fabric, especially on tiny boards or when coated for environmental protection.

so changing the part number for every major change is not actually feasible.

Also, many part numbers, especially at the assembly level are used in test documentation and other documents, such as an early BOM to customers who track change under contractual change accountability.

One problem, is that the production based view of part numbers, forgets that these have lived a life for maybe 2 years before release.

all the developers have remembered what they are, and many requirements are linked to them.

Changing that design identity involves a re-linking of information.

if you now look at the implications of changing sub assembly parts in a BOM of say 3000 individual parts, it would be never ending, especially in the initial phases of a products release life when things are discovered and improved quickly.

I am trying to get to a holistic solution which gets the middle ground between all stakeholders.

R&D are usually overburdened, and do not have the capacity to fork part numbers with every major change. In a way, we are still saying the engineers have to make a call. Major change == new part number. Minor change == Up revise.

Does this make sense ?

In 20 years of engineering management, I have not seen other than stalemate so far, and it ends up with some manual mechanism to paper over the cracks.

[SG_14118493]

All that said, I agree that a change should just be a change whatever the perceived level.

So I am suggesting, let us get away from the concept of major and minor and rather say "wholly compatible with previous revisions, or not".

If not, then it is in a pure sense, the requirements that have changed or been changed.

So maybe the answer is to introduce an extra "stepping" field. This would be changed outside the concept of revisions, and that would allow the compatibility to be assessed after the revision has been released and tested.