With Product Lifecycle Management (PLM) some people identify software applications used to manage product data. This definition is both imprecise and lacking, as PLM is not a product and cannot even be identified with the sum of the functionalities of all products available in the market.

PLM is a discipline (or set of techniques) that allows companies dealing with products (mainly manufacturing ones, but not only) to manage all product information in a dynamic way, from birth to obsolescence, while these data flow through different companies or corporate entities who design, assemble, sell, support and dispose the product itself. 

Even for moderately complex products, this means large amounts of data, created using different systems with different formats and meant for different uses: textual documents, specifications, manuals, 3D CAD models, 3D FEM models, results of tests and simulations, costs, etc. 

More than anything else PLM means  keeping order in the chaos of the changes that these data undergo during the product life and being able to reproduce a consistent set at some point back in the life cycle.

Some people make the mistake of believing that implementing a PLM system in a company is a matter of introducing a software application and focus on the selection of such a software. Nothing more wrong! A PLM project means to analyze, understand and improve the processes followed in product development and to represent this in a computer system so that it is easy for anyone to cooperate for the product realization. Therefore the attention should be on process analysis not on PLM software.

Click edit button to change this text.

archivio elettronico

The first functionality allowed by the earliest raw systems, or the function that alone justified the first PLM systems. Today it seems hard to believe that maintaining a single logical database could be such a difficult task to achieve, but we have to look back in the 80s perspective, when there was a larger number of different operating systems, proprietary networks and limited standard communication protocols.

Nevertheless the first PDM systems could manage setting up a unified logical archive, physically distributed with volumes on different operating systems and even allowed data to be physically moved across different devices (magnetic, optical, etc.) based on their different stage of the lifecycle: almost science fiction for the 80s!

Furthermore the data backup and recovery activity was easily managed.

But even today the key function for large groups of engineers is the “check-out” and “check-in” one which allows the group to cooperate in a non-destructive way on the product data.


Unfortunately it doesn’t help that different PLM vendors use the first two terms in opposite ways. It has to do with the possibility of having more instances of the same onject (e.g. a 3D CAD model describing a product component) designed at different times in order to correct mistakes or to satisfy (slightly) changing needs.

A good PLM system must allow for the creation and management of any of these and shall be able to answer the question: “Which version of this component, among the many existing, is to be used now, for this product”?

Already during the design phase, by breaking down the product into systems, subsystems and components engineers define to a certain level of detail the product structure and the first of the many “Bill of Materials” (BoM) which will come into life: the engineering (or design) BoM.

The graphically suggestive idea is to represent the BoM with an indented list or, better, with a tree representation with nodes as different icons to represent different types of items and and branches in different colours to represent different types of link or relation.

To manage the product structure means, for a PLM system, to allow creation and modification of links and manage their validity criteria (e.g. by type of BoM, by time, by effectivity). It also means to be able to perform collective actions on a product subtree (check-out, CAD session activation, transfer on the network, visualization, etc.). All while maintaining data integrity as they are partially created and modified in the CAD systems.


As the first PLM systems have been essentially dedicated to design departments it is obvious the need to facilitate and automate the data exchange with the main systems used in that department: CAD systems, mainly MCAD.
The first need was to store and retrieve data in the vault and to activate a CAD session on them. Once the design stage is completed the engineers want to store data in the vault with a simple command without worrying about the physical location of data. Then it is necessary to manage teams of engineers who need to work on the same data set, possibly from distant locations.

From these simple functions CAD integrations have evolved to become more sofisticated and include metadata exchange between 3D models and the PLM database, automatic creation and filling of title blocks or balloons for 2D tables, check-in and check-out on whole assemblies, “caching” mechanisms to optimize network traffic for large assemblies, etc.

CAD integrations have been and still are so important that often availability of good integration packages with the most common CAD systems has made the success of some PLM systems. Perhaps it is not by incidental that the natural selection among PLM vendors in the last ten years has left mainly MCAD companies.


It’s the discipline, well known by the technical departments, which, in a design department, rules technical modifications to a product or to its components. It implies to maintain whatever formally released before the change and to allow the company to answer the questions:

  • what changes are applicable to the product which is now going into production?
  • which one have been applied to the last month production?
  • who has requested, justified and approved the changes?
  • has the impact of the change to other components, to production costs, to the inventory, been evaluated?

For this a PLM system is mandatory as it enforces company’s procedures, internal or regulatory, and makes operations traceable, allowing reporting all details about decisions taken.

A PLM system can be part of a complex ecosystem of company information and therefore it can need to integrate and to share part of the data with other enterprise systems. Think about Customer Relationship Management, Supplier Relationship Management, Manufacturing Execution System, Knowledge Management System, Document Management Systems, etc.

Even if, for some of the most widespread commerical systems, integration packages are available to ease the integration, nonetheless integration must be carefully planned and technical decisions here often involve top management.


Sometimes enough to justify an investment, the workflow functionality allows to organize flow of information across the company (extended or not) so that every single person in every department involved in any action related to the product, can accomplish its task rapidly and with all needed information at hand.

One needs to let each person get on his desk notification of progress, requests for signature, all realted documents, to allow to sign electronically, to trigger alerts and stage change. This implies the ability to define user roles, groups, rights, access control and signing power.

In order to reach users outside the PLM community the workflow is often integrated with company’s e-mail system and notifications can also reach cells or palmtops.

shutterstock_96459767By this term we mean different functionalities in different markets all having a common background in terms of PLM functions. In the Aerospace & Defense market it is a well defined and coded discipline to get the highest control of the BoM and of all related documentation throughout the whole product lifecycle and consists of:

  • Configuration Identification, i.e. to define the physical and functional characteristics of the “items” which make the product and to uniquely identify the documents which will form the “baseline”; to produce the Functional, Allocated e Product “baselines”.
  • Configuration Control, i.e. to set and enforce the rules governing the modifications to the product structure and to the describing documents.
  • Configuration Audit, i.e. to track all changes applied and being able to report at any time on their implementation status.
  • Configuration Verification, i.e. to be able to check at any time during the lifecycle the conformance of a any “item” in the product structure to the defined characteristics.

In other markets it simply means the need to apply defined rules for technical modifications and to maintain their traceability.

Finally there is “Sales Configuration”, by which we mean to enable the sales department to propose and sell to cusomers specific configurations of the product fulfilling all technical, geographical, marketiing and regulatory constraints.

The base functionality in the PLM technology allowing all the above is the possibility to maintain multiple logical links between a product assembly and the many variants and revisions of its components and the ability to set rules for selecting among them in order to produce the BoM at any time.

In alcuni settori industriali quella della classificazione delle parti di progettazione o di acquisto è una esigenza molto sentita.

In some industrial segments components and parts classification is a strong need.

PLM systems are particularly fit for this role because of the object-oriented nature of many modern systems’ data model and a few of them have gone far.

Characteristics for this functionality are flexibility in defining and redefining the classes, class trees, and possibility to feed the database from external sources.

In some areas (e.g. electronic components) it is important to be able to integrate external classification systems as they are available from commercial and public domain sources.

ERP differs significantly from PLM, even if limited to managing product data. Once the design intent is defined, ERP systems focus on how to manage production related issues: managing inventories, sourcing, manpower, plants. A common factor for both systems is the “Bill of Materials” or the product structure.

But the approach is different: PLM product structure and attached docuemnts describe the physical characteristics of the product, its components, its functions and, possibly, actions necessary to produce it. An ERP BoM looks at the same
component from a “as-built” point of view, or as the product is assembled in the factory. The production BoM can include elements such as raw materials, routings, calibrations, “phantom” assemblies used to producte, but do not reflect the design intent. Beyond defining BoMs, ERP manages inventories, procurement, production processesand scheduling. Besiddes a ERP system sometimes extends to accounting, human resources, sales and other functions of the enterprise.

ERP systems technology has evolved at a slower pace, while PLM systems have followed the tumultuous development of design systems, are technologically modern, more flexible and more suitable to be configured and customized.

Therefore we have two well distinct systems, both fundamental for manufacturing companies and the best from them can be obtained if they are properly integrated.