Product Structure Parts

The Product Structures Parts shall support: 

1. Product Engineering and Manufacturing Engineering

Different user groups will require different views and different "slicing" of the Products, such as: 

  • The entire Product but subdivided by Function Groups 
  • By an entire System such as Electrical System, Hydraulic system, Pneumatic System etc. subdivided within each System. 
  • The entire Product but subdivided by the Plants where different Components and Assemblies are manufactured. 
  • The Entire Product or a View shown within a Time Interval where Parts that will be "current" depending of the effectivity in different ECNs will be shown.

Combinations of these and a few more. 

 2. Product Development Projects

from the start which means that there must be a capability to differentiate between 

  • what is Under work and not yet released for manufacturing 
  • Released and in current production 
  • Phased out of production and obsolete (history). 

In other words: The recording of the entire Life Cycle Management for the Nominal Product from "before the conception until the grave has been recycled"!. 

3. ECNs

​from the creation of such, through approval and release until they are implemented and the effectivity dates and serial numbers for this has been captured. 

4. Parts Planning

where the contents of the Parts Manuals are decided and specified. This requirement means that they will want access to the Product Structure with all the ECN-history for at least 20 years or so after the product has been phased out of production. 


Principal Variant Specification or "PV-Spec"

The PV-Spec is a BoM with an information structure that will enable the specification of the Nominal Product as it will be, is being and has been manufactured, independent of which Plant it is manufactured at and independent of where in the life cycle the Nominal Product is. The user shall be able to retrieve officially released Product Structures with 

•    the latest released Engineeiring Changes regardles of whether these have been effected or not: "Engineering Status" 
•    all released and effected Engineering Changes as the Product is being manufactured at the moment of retrieval: "Manufacturing Status" 
•    some Engineering Changes effected specified by a Date in the past or in the future: "Spec Date Status"

Function Groups.

The PV-Spec is based on Functional subdivision in order to achieve a manageable number of PV-Specs with not too many or too few Product Structure Records per PV-Spec. It will also be easy to find what you are looking for when you have learnt to navigate using the Function Groups.

It has proven very practical to have a functional subdivision of the Engineering Product Structure or Engineering BoM. As a Product is being developed initially and as it is later maintained it is important to the Product Engineers that can easily find the function they are going to update or change etc. The Function Groups have to be established by the Product Company or the Business Organizations to which the Product Company belong (Automotive, Aerospace, Diesel engines, Mining, Pumps, Ventilation etc.) and should be purely functional.
By pure function I intend a subdivison of functions within the Product with focus on function alone, not what drives the function.
An example: a windscreen wiper is cleaning the windscreen regardless of whether it is driven by electricity, hydraulics or pneumatics. The cleaning function is the important factor.
The "Electrical System" or the "Hydraulic System" is no Function. These are systems in their own right which deserves their own classification system and sub-groupings.
The Function Groups should not be confused with Parts Classification even if there are similarities.Function Groups should include Functions of any Variant/Option existing for the the Product.
A System Classification will never cover the entire Product, only the System it is classifying.

The Product Structure Record (PSR)

 It should in principle look something like this:

A Parent Part Number may identify a material heap needed when one Variant/Option is selected for the same Product Instance/Customer Order.

A Parent Part Number may also identify a material heap needed when two or more Variants/Options are selected for the same Product Instance/Customer Order. 

The Parent Part Number for the top of the Product Structure Parts  is often a suitable ID to be used for Material Requirements Planning in the MRP Applications. This Part Number or the equivalent Variant or Variant Combination may be called a Program Module since this Part Number will define a group of parts specific for this Combination of Variants/Options and suitable to use for Requirements Planning when a percentage of the manufacturing program has been assigned.

The relation to the Function Group is vital and the most important View of the BoM.
The Functional subdivision of the PV-Specs should be based on profound Product knowledge. 

The PSR should also be defined where it is valid in time.

I.e. the ECN or the ERN (Engineering Release Notice) with its effectivity should be set 

  • per Variant or Variant Combination and 
  • per Plant 

in order to define when a certain PSR should exist or not. 

The yellow boxes are related to the Product Structure (relation between Parts). The blue boxes are related to the Engineering Changes and Releases. ERN is short for Engineering Release Notice and should also be used for the release of brand new Products. An ERN (or if you prefer ECN) is not worth very much unless you also specify when the ECN should be effected at the various plants. 

The Quantity should always be single occurrences in the database in order to provide for Geometric Models in a Geometric View of the Product or part of the Product, so called DMU or Virtual Product. However, it should be possible to specify as an update, a quantity for groups of parts (bolts, solar gears etc.) to be managed by the database and the application logic. 

Quantities with fractions or decimals are assumed to be parts of a certain surface, volume or mass and with one geometric location in the Product. 

The yellow View boxes represent alternative views of the Product Structure.

Generic Product Structure.

A generic Product Structure is a tool to shorten time and reduce efforts for Product Documentation and at the same time decrease risks for errors.

Most of the Parts listed within a PV-Spec are well known and they can have various attributes/properties and they could also be classified in Part Classification (generic functionality and properties independent of Product Structure usage).

Below is a model that is intended as an explanation of a "generic" or "phantom Engineering BoM" that can support the Product Development in early phases. 

This is a model of a simplified and not fully defined PSR. 

The Parent Part/Top of the Heap P/N may represent a bunch of Parts that is necessary for a certain combination of Variants/Options needed on some Products within the Product Class.

The Part is represented by a Part Class from the Part Classification System.

The Function Group has properties and definitions same as is used for the real Products within the Product Class. 

However, there is no definition of when this PSR should be effective for which Plant. This is still missing, but will have to be part of the fully defined PSR.
See slideshow. 

PV-Spec presentations.

Common for all the Product Variant Specifications or PV Specs and other ways to present the structure:

The PV-Specs are not part of the actual Product Structure.

The PV-Specs are just used to present the Product Structure, similar to the pages in a book which is just there to present the written text (it could just as well have been presented as an html-document or been published in a newspaper or at the back of a cereal box). The information may be the same in all cases. 

In the adjacent figure a PV-Spec will present a small portion of all the parts used to build the Nominal Product (dotted line).

One record in the PV-Spec represents one PSR 

The presentation of these Product Structures may be in several different ways. Which way to choose depend on which is best for the Products of your Product Company.

  • Matrix forms may be suitable for very complex products where you still want to present several Variants or several Variant Combinations in order to show the commonality and the differences between the listed Variants or Variant Combinations. 
  • The same Product Structure may be shown in a different way if the complexity of the Products is less. 
  • The above may be shown within a Time Frames for ECN Effectivity 
  • Showing a single Variant or Variant Combination at a time with or without a Time Frames. 
  • Etc. 

One way of obtaining Life Cycle Management for a Nominal Product can be by using the technique with "Time Frames".

The users specify which status they need:

  • Engineering Status (as designed) or 
  • Manufacturing Status (as currently manufactured) or 
  • a Time Frame (from date – to date), historically (as manufactured at a given from date) or in the future (engineering projects) giving a status (implemented ECNs) 

when ever asked by a user.