revision or create new code

[Davimont]

the question revised is always very articulated and here I am with a new question.

I have 2 series of machines, red series and blue series to do the example.
machines always try to revise them by series so that they are all consistent with each other and at an annual rate not to have revisions every 2 days.
both the red and blue series share components.

the time comes to review the red series.
the blue series will be revised in 6 months for productive issues.

now the question is: is common components preferable to review them or create a new code?

in six months it would be much more convenient to see which components received a revision and replace them accordingly instead of going to look for the old code correspondence - new code.

if you review the individual details, the main problem is that: if I order today the red series revised and in a week the blue series not revised, when the suppliers are to produce the blue series they call me because they find in archive the codes of the individual components both in revision 0 and 1 and ask me if I want the most recent one.
every time I explain that the blue series must maintain the old revisions because it has not yet been revised but I would like to understand you how to do and if you happen these situations.

Sorry about the papyrus and I wait for your experiences.
Thank you.

 

[radio]

bye davimont

I'll make it short, then if we need to deepen.

we are quite Taliban about it, we consider revised only the elements (from the pin to the total carpentry of some ton) that are 100% interchangeable with the previous ones (the revised elements are usable/mountable instead of the previous ones).

If not, even if the change is minimal, the modified pieces take a new code.

this system avoids misunderstandings with suppliers and simplifies the management of spare parts; against a revised piece that enters into force does so for all machines that share it.

 

[Davimont]

Hi.
We share the same logic for review, even I revision only interchangeable components, otherwise I make new code.

this system avoids misunderstandings with suppliers and simplifies the management of spare parts; against a revised piece that enters into force does so for all machines that share it.

I always provide a list of the components contained within the machine and this shows both the code and the revision of the single component.
to show the last revision of the various components in all machines I should take them all in hand and review those, which I can't do every time.

I should come in the perspective that a component with older revision should no longer be produced and tell the supplier that the code with higher revision prevails on the lower version.

Obviously every productive reality is different from the others and procedures can be the most varied. I have white paper on the management of the badges because I work in a small reality and I am the only designer, so I want to feel how others behave.

 

[asblo]

where I worked before there was a structured coding the component code was unique and never changed (also because it is a slaughter with administrative management), what changes is the revision code and besides being well highlighted in the table, I made a new pdf file with _01 (or _02, _03 etc...) at the end. the part file code did not change, what made faith was the pdf sent. so I also kept an archive of changes because every pdf had the latest progressive figures

 

[DrBarde]

also from us the management is linked to the interchangeability, so only if the component is 100% reusable in the previous machines you do the revision, otherwise new code.
This ensures that the review can be done at the time of reporting non-compliance, making the management even of the leaner and immediate quality, despite we have an archive made by tens of thousands of components (we work very custom).

 

[Davimont]

the concept of revision only if the piece is interchangeable is clear to me and I put it into practice too.
I try to imagine a workflow to explain myself better maybe extinguishing some time.

Today I have a red series machine and order it because I need it shortly.
to follow I will bring back all the changes on the remaining machines of the red series, let's assume that for all machines I need a month.

Next week though I get the order of any blue series car.

I have not yet updated the blue series so inside it there will still be parts with revision 0 instead of 1. what do I do?
I still order the blue machine today and if the supplier calls me because it has noticed that in the destined parts appears a detail with revision 0 while in its archive has the same part with revision 1, I tell him to respect the revision reported in separate parts. If you do not ask me anything and provide me with revision 1 there is no problem but I would like to avoid discrepancies and that you stop to clarify these doubts.

I hope I made my question clearer. :

 

[Steppermotor]

we also use the same philosophy that I read for everyone, if there is retrocompatibility revision otherwise new group and new parts.
Now if you were in your own situation with two different series of machines that have a different revision policy, at this point it would be to think of using for the two machines groups and parts with new codes and you get rid of addictions and misunderstandings.
I can tell you however that we also use parts in common and many are old years, if over time they need revision and how by definition they have retrocompatibility we go on this direction otherwise we make new code and it is over there, so then the production sends all the designs to the supplier, normally the supplier, at least ours, do not ask so many questions and do the pieces.

 

[Davimont]

thanks to all for the various feedback.
I have not yet decided how to move but I am leaning to divide the components by various lines and therefore with different codes.

 

[Kaji]

first of all it is necessary to distinguish whether particular and groups are part of a "prototype" or of a machine made for the first time and in a single specimen or are part of lines already sold previously for which there is the manuals exchange etc etc.

If the details and groups are made for the first time well or badly you can be less taxable and streamline the bureaucracy, i.e. I also tend to change the details by keeping the same code, I am only very careful and do the review if the particular has been shown to a supplier for quote etc, because I do not want it to have two different designs with same code and same revision.
the groups instead made for the first time, the assembly is always internal, I overwrite them and enough, at the most I do the revisions if I want to keep track of the evolution of the group.

If the details were already built and given to the customer the question is more delicate, however for me the sufficient and necessary condition so that a modified detail retains the old code with revision is the "retrocompatibility" and not "interchangeability" i.e. the new piece sent as a replacement must fit and satisfy its function also on the old axieme, while the opposite is not necessary. if in stock there are still particular "old revision" they must be modified in order to become like new ones if they are not interchangeable.

for the overalls, however, even if the group in its set is retrocompatible you have to take into account the manual exchanges, that is, if the separate change is necessary to change code otherwise two customers with the same code have different spare parts page.

Finally I think it is necessary to specify not only what the revision is, but also the reasons why it has decided to make it that classically can be: cost reduction, improvement or design error.

 

[Davimont]

thanks kaji, excellent explanation.
where work we are much less structured and there is no spare parts available to the customer or manuals that impact on the construction of the machines but it is always better to keep a certain order in the design.
I also tend to review a component if this is replaceable to the old one otherwise I create a new code.
in the end I decided to divide the components by lines of machines so as not to have overlaps of components don different revisions.

 

[ceschi1959]

Today I have a red series machine and order it because I need it shortly.
to follow I will bring back all the changes on the remaining machines of the red series, let's assume that for all machines I need a month.

do you review the machine if you review one or more details of the same?
from us the revision of the axieme happens if and only if a component changes code. It may be that the same component I've changed my code is good only on a certain set or it's good on multiple assemblies that contain it. two or more scenarios open: on the first group compulsory use the new code while on others can be mounted indifferently the old or new code, in this case the old goes to exhaustion stocks, so revision the first together while I do not raise the revision of others if not when I issue the new code.
the new code is a enhancement for all assemblies but it is not mandatory to mount them immediately: they revision them all and only valid them when the change will become effective.
the new code must be mounted on all asses, scrap the old code, revision the axieme.
all managed with ecr.
I hope I've been clear.
Hi.

 

[Davimont]

read a few times and then became clear di
I review the axieme even only for a revised code, the revision forces my supplier to check all the parts list to see what has changed.

By reading your answers I realize that every reality is different from the others also the general rules are worth a little for everyone.

thank you also for your contribution.