Hello everyone and happy new year.
In the PLM/PDM world, we often see the reference to Product Definition. That PLM is to manage it. etc..
But what is it actually ? How does it compare to the Product Structure and is there an universal standard definition so that everything single company when using PLM should use.
My view is that each company will define the product definition differently.
Here is my try to define it though.
I am taking a bottom up approach.
To define a product (first a component) I will need the following object
When using PDMLink I would add that a WTpart is also required.
Nonetheless I think this not enough as part of the definition is its history. when talking about the history (iteration of each element), the configuration must also be taken into account
Talking about assembly we will find something similar
but here we have a new element which is the BOMs.
Should only the eBOM be part of the product definition or all of them (As Manufactured, As delivered, As serviced etc....)
and of course its history and the configuration. (latest non latest )
I think it is necessary to define levels for the product definition. The basic one should include the documents (CAD; documents)
up to a more comprehensive one which includes relationship with other parts (due to inheritances, dependencies with other CAD),
I exclude 2D drawings and derived BOM (such as mBOM) because they are just representations of the product (definition) from a given purpose.
What do you think ? Would it be worse to publish a definition of the Product Definition for the community in order to help them define their PLM strategy and implementation.
How do you see it ?
Thanks and best regards
New year does not start well.
I've forgotten to include classification (parameters/attributes) as element of the product definition.
I originally come from a Manufacturing background in the Automtive industry which has built my view on this. Our product development process is based off of APQP standards which I've found to be quite rugged and have a good amount of detail.
Product Definition is a rather broad term that basically contains every single bit of information to tell you what a product is, why you need it, how you make it and how you support it/maintain it. This would include:
1) Intent of the product/customer's request/whatever you want to call it, the primary reason why this product is needed in the first place. A full breakdown of what activities it is supposed to do, what capabilities it is supposed to have, what industrial guidelines/policies it is supposed to follow. In layman's terms, why are you bothering to design and make it in the first place?
2) Product Structure, which you mentioned, the direct bits and pieces you need to make this "thing" you're designing comply to everything in 1).
3) Product Sourcing Method. Is this product going to be manufactured by you, completely or partially? Bought from someone else? If bought from someone else, which supplier will do it? How do you confirm they're making it properly, at the production rates you need? If you're making it in house, how do you do that? In which order do the components go together? What tools do you use? How do you know the tools are working properly and accurately? How do you test the final assembly to make sure it has been built properly to comply to everything in 1)? Could the design in 2) be modified to make assembly either by you or a supplier faster, cheaper, safer?
4) Field Support. Physical systems will wear out in time. Are you able to cheaply maintain the product by fixing/cleaning/replacing certain subcomponents to make it have as long a life as possible while still being able to fully comply to everything in 1)? How is that maintenance performed? Could the design in 2) be modified to make the maintenance easier, safer and/or cheaper without negatively affecting 3)?
All of the above aspects need to be considered when you define a product. This is why it's always good to have a cross-functional team in a company with experts that think almost entirely in each way of 1) through 4), as well as collaboration managers who have a bit of a more general broad knowledge allowing them to at least understand those four aspects and properly link them all together.
Hope that helps,
Engineering Systems Analyst
thank you for your emails.
I made a presentation (it took me some time !!!!) and the best bit (I think)is how the definition of the production definition growths. This was presented to the new group leading PLM. Interesting is that one of the guy found that slide with the full diagram too complicated . I have asked him why, was there something in that slide we do not have. He could not reply, as usual. Many people speak with perception rather than facts. and they take decisions like this. However, when I said well, if that is all what we have as data related to product, then I manage to fit that into one slide while normally it is scattered into many different systems....
Anyway. find it in the attachment and please tell me what you think. and if you have any questions do not hesitate to ask.
I hope this will also help a few people.
Glad to see I had an influence . Hope it goes well for you.
Engineering Systems Analyst