	Isene PDM Home
	A PDM Introduction

Product Structure

	In General

	Product Structure Variants

	Product Structure Parts

	Product Structure Views

	Engineering Changes

	Configuration Rules

In General

Product Structure in general　

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 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 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 1 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" – as opposed to the records maintained for each "Product Instance" as their Life Cycle Records. The Nominal Product is used here as denomination for a Model with all its possible Variants/Options.
A Bill of Material is not 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 on when they manufactured a certain Product Instance in the past in their MRP applications. Each Product Instance built will be updated in a Product Instance database with the 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.

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 Configurators used 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 become a "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.