With ”Product Structure” we normally intend a way to view what used to be called ”Bill of Material” or BoM. A computerized Product Structure will, of course, offer several ways to regard the BoM – an ability the old BoM did not have. ”Where used” is such a typical enhancement.
A Product Engineering version of the Product Structure, often called EBoM is a tool that helps the Product Engineers keep track of where they are regarding the development New Products or Engineering Changes and the release of these.
A Manufacturing Engineering version of the Product Structure, often called MBoM is a tool that helps Manufacturing Engineers to keep track of how they assemble the Product and how they regard the options of the various Products they are building and which released Engineering Changes they have effected and which they will effect in the near future etc.
Product Structure is born through Product Engineering and should be flowing ”downstream” through interfaces to Manufacturing Engineering and and other users of such data.
Here is an illustration of this way to see the Product Structure.
Which are the requirements you should have on a PDM application regarding Product Structure?
It is obvious that there are lots of people and lots of applications that use and reuse the PDM information.
Should the PDM application include the Product Development functions normally done within Manufacturing Engineering such as deciding the effectivity of an Engineering Change? – or should this be done in an MRP application?
It may be practical classify Product Structures as
- Engineering Structures as used for mainly Product Engineering and will mostly show ”As designed” status.
- Manufacturing Structures as used by Manufacturing Engineering, mostly following the flow of operations – often split by Plant and Assembly Stations and will mostly show ”As manufactured” status.
A PDM application may serve both purposes or just the first. If the PDM application does not necessarily support the Manufacturing Structures, it will be necessary to provide two-way interfaces between the PDM application and the MRP application to communicate ERN/ECN information to the MRP application that contains the Manufacturing Structures and to return info about when an Engineering Change is effected in manufacturing.
A PDM application should allow ”under work” update of the Product Structures for new Products and updates of Engineering Changes under work. Product Development Projects should be allowed to update Product Structures from day one in the project. Transfer of pieces of the Product Structures from the Product to be replaced to the new Project should be made easy. Part names should be allowed where Part IDs have not yet been decided etc.
When the Product Structures under work is ready, it should be released as Official Product Structures.
Official Product Structures are liable to Engineering Changes (ERN/ECN).
Engineering Changes should be possible to back out as long as they have not been effected in manufacturing.
Records should be kept of all Engineering Changes including when they were effected in time and when possible, by serial number. These records should, in principle, be maintained ”for ever”.
When the Product has become obsolete, it should be possible to move the Product with all related information, including the entire Engineering Change History, to the ”Historic PDM database”.
This is part of the Life Cycle Management for the ”Nominal Product” – it is different than the records maintained for each ”Product Instance” as their Life Cycle Records with a pertaining Product Configuration Record. The Nominal Product is used here as denomination for a Model with all its possible Variants/Options.
A Bill of Material may not always be the same as the Product Structure.
Manufacturing Engineering is basically interested in what they are manufacturing right now and what they are going to manufacture in the near future.
They do not keep any records in their MRP applications on when they manufactured a certain Product Instance in the past . Each Product Instance built will be updated in a Product Instance Database with the specific configuration of the Product Instance. The Product Instance database contains important information that can be used by the Parts people and the Service people to be able to service the Product out in the field.
A Bill of Material or BoM is a paper or a computerized representation of this paper that holds some information derived from the Product Structure presented according to a user requirement.
There are two Types of Structures within the Product Structures
It is prcatical to differentiate between two portions of the same Product Structure:
- Product Structures Variants
- Product Structures Parts
They are both needed in the complete Product Structures and the complete PDM application.
The Product Structure Variants handle Variants/Options in the top part of the Product Structure and is closely related to The Configuration Rules used in the Configurators in the Order Entry Applications. Apart from defining the Nominal Products by Variants, Variant Families and Product Class etc, the Product Structure Variant also contains all Configuration Rules defined to prevent impossible or dangerous combinations of Variant/Options.
The Product Structure Parts handle Parts that contain Parts in several levels down to single Parts and/or raw material. In order to define the necessary parts on the top level of the Product Structure Parts for an Option/Variant or for Parts necessary for a combination of Variants/Options, such ”Heaps of Parts” are given a Part Number.
Such Part Numbers will always have an equivalent (alias) Variant or Variant Combination in the Product Structure Variants.
Why this?
Most enterprises have a legacy PDM application (or MRP application) that can be developed further. Normally the Enterprise haven’t used Variants yet but very often they have grown out of the current PDM application. The PROST application at Volvo CE is rather typical.
By adding the Product Structure Variants on top of the existing application and develop this a little further, it will be possible to get a PDM application that fulfills the requirements without having to change everything. The old legacy application can continue to run with a new front end that will look new and smart.
When to select a vendor solution.
If you buy a vendor solution you will possibly get a solution with restrictions based on from where the solution has been developed.
- Some vendors initially developed an MRP application – with some additions, this has later becomes a kind of ”PDM application”.
- Some vendors started off in the CAD business – with some further development they are now ”PDM vendors”.
- Some try to ”solve it all” – SAP is such a vendor.
It is hard to evaluate which suits best. In any way – a vendor’s PDM solution should be chosen only after the enterprise has developed a PDM Object Model and has defined their requirements and which processes or Use Cases the PDM application shall encompass and fulfill.