Product Structure

What is meant by The Product Structure?

Product Structure is the detailed definition of how Parts are related to other Parts and how parts are related to Models and Options within the Models and how these relations are changed over time as the product changes and develops. 

This is described in a structured way for a number of reasons:

  • Engineers will have to find their way in all this information – The Product Structure has to offer several ways to find what is required at the moment the engineer needs the information. 
  • Manufacturing will need the information contained in the Product Structure but adapted to their needs. 
  • Marketing will need some of the information in order put price on Models and Options and to adapt the variety of Options to various Markets etc. 
  • After Market will need the information in the Product Structure in order to make Parts Catalogues and provide Spare Parts at an adequate level etc. 
  • The Engineering Changes are documented in the Product Structure and Processes around the Engineering Changes are several – nearly every department in the company are involved. 

Product Structure is central and common in any company developing and producing complex Products. There are normally plenty of interfaces from the PDM application to downstream applications.

Basic Principles

The figure shows some important principles that I have chosen to apply in my way to structure the Product Structure Information. This the way I recommend when the Products to be documented in a PDM application will have lots of Options (>100). 

I believe it is essential to differentiate between the way the information about Parts and about Variants (Options) are handled since the information is very different.

The two Information structures have a ”marriage point” where they meet and where the Top Material Heap Part Number of the Product Structure Parts meet the Variant Combination from the Product Structure Variants.

The two information structures keep track of Engineering Changes separately on Engineering Release Notices (ERN or ECN) that makes it possible to continuously follow up changes to the information structures and roll back information about engineering changes to any given date in the past. 

The PDM database should always be organized according to a general data/object model based on actual relations between information objects regarded as necessary for the company’s PDM data. See the chapter ”Objects and Interfaces” under ”PDM in general” for further info. 

The Data Model used in a PDM system should never change dramatically! 

After the initial development, it should be developed slowly and with great care because the Data Model is the result of the experience of many people and some scientific expertise. Also, when a Data Model is well established, there will be a large portion of the employees of the company that will have this Data Model well drilled into their heads and spine. 

The same data may be updated in several different ways depending in which processes this should be done. 

(The Top Material Heap P/N indicated in the figure will be the equivalence of the Product Variant or the Equipment Variant as used by Volvo CE in the PROST application).

Each of the boxes in the figure will be described in separate chapters.

Bill of Material

The Bill of Material is one or several ways to present the information in the Product Structure. The Bill of Material, or BoM, used to be printed on paper and had a revision number. To-day it is one or several real time presentations on a computer screen, showing the actual state in the database.

There are other types of presentations existing, used to show the information contained in the Product Structure but these are called other names like ”Where-used”, ”Part Specification” etc. All should be based on real time access to the database. 

The different screens needed to present data and to capture data should be adapted to

  •     The way data is organized in the database and
  •     The processes needed to capture the data
  •     The solution provided in a purchased vendor application

The third requirement will be a must when a vendor application is at hand.

Life Cycles of the PDM information and the PDM application etc.

The information about the products stored in the PDM Data Base has a very long life cycle or rather – a very long life. By law it should be saved in a secure way for at least 30 years or as long as old products are still maintained at the company’s dealer workshops. 

  • The lifetime of the computer hardware is today regarded as maximum 5 years – normally 3 years. Computers should be possible to replace often. 
  • The life cycle of the PDM software may be up to 10 years and even more. That is the maximum a vendor can wait until he or she has to release something new and exciting! If an enterprise has developed the software in-house, it will of course be possible to maintain the software much longer.
  • The Data Model or Object Model should last much longer – at least as long as the basic principles of the Products developed and manufactured stays the same.

These ”Life Cycles” should be regarded with great respect by anybody who has got a task to develop the PDM application at hand – the so called legacy application – into something new and presumably better. 

Some important definitions:

Product: 

A very flimsy word that may mean almost anything from the hardware purchased by the company’s customer to the service the customer gets to be able to purchase the Product. The financing service is also called a Product. 
In order to be able to make myself understood I am going to use the words with the definitions listed below.

Nominal Product:

This is the Product as it is talked about within the Product Engineering Departments and Product Development. It is a common name for all theoretically possible Product Instances that can be built within a Model including all Options or Variants developed. A Nominal Product is always related to a Product Class and comprise all documentation related to a Model.

Product Instance:

This is one specific Product being built on the assembly line based on one Customer Order. The Product Instance will have a Serial Number and probably a Product Number telling which version of the Nominal Product or Model this is and also when it was built.

Product Class:

A Product Class is an identity for all Models with a common set of properties. Within the automotive world Product Classes may be: Car, Truck, Bus, Wheel Loader, Articulated Truck, Excavator etc. Product Classes are also used for Component Products like Engine, Gear Box, Cab, Axle etc.

Model: 

A Model is a common designation for a set of Products that have common properties such as Size, Capacity, Speed, HP, Weight, Purpose etc. Model is often used as a specific designation for a Nominal Product. A Product Instance will always be related to a Model. 

Option or Variant:

An Option is a foreseen feature, function or property that can be requested by a customer and added to the Customer Order. An Option is an integrated part of the Nominal Product as developed by Product Engineering. A synonym to Option is Variant as used by Volvo. 

Variant Combination & Top Material Heap P/N:

A Variant Combinations is an identifier for a specific ”heap of Parts” needed to assemble a complete Product Instance. The Variant Combination may consist of one or several Variants (Options). The Top Material Heap P/N is an alias for the equivalent Variant Combination. 
A Material Heap is in this context a specific set of Parts necessary for a specific purpose. It could also be Parts needed for a specific function or part of a function or for an option or an option in combination with one or several other options. Material Heaps are configurable Parts. 

Assembly: 
An Assembly is a Part that consists of more than two single parts or sub-assemblies that can be assembled and disassembled. An assembly will be identified by its Parent Part and its Constituent Parts and the appertaining Part Numbers. Permanently fixed Assemblies may also occur even if they are not possible to disassemble. Assemblies are non-configurable Parts.

Part: 
A Part is anything that can be identified by a Part Number (P/N), hardware or software and even drawings, geometric models, specifications etc. In a Product Structure we normally assume that Parts are Hardware or Software.

Bill of Material or Part Specifications:

See definition above.