Abstract This case study shows how the PLM environment has evolved at GROUPE PSA since the 1960s. During the initial period, the focus was on systems that mainly addressed the specific needs of individual departments, and improved the perfor- mance of individual engineers. Work processes were organised around drawings. This approach changed in 1998, with the INGENUM project. Its objective was to set up a progressive reference frame for product and process definition based on a single physical digital model for all product developers. A third phase started in 2012, with the COMPANY PLM project. The objective of this ongoing project is to integrate all data related to the design, manufacture and maintenance of automotive products, including software components, in a common corporate repository for all participants. The scope, approach and lessons learned are described for each phase.

Keywords PLM · eBOM · mBOM · DMU · Digital Factory · System engineering · Configuration management · Variant management


GROUPE PSA is a French mobility provider that designs, produces and sells cars and motorcycles sold under the Peugeot, Citroën, DS, Opel and Vauxhall brands. Its vision is to become a leading car manufacturer and a provider of mobility solutions to enhance its customers’ freedom of movement on a day-to-day basis and around the world.

In 2017, GROUPE PSA had revenues of e65.2 billion, sold more than 3.6 million vehicles, and had 212,000 employees.

GROUPE PSA is present in some 100 countries and develops activities in six strategic regions: China and South-East Asia; Eurasia; Latin America; Europe; India- Pacific; and Middle East and Africa.

To support the brands’ global ambitions, GROUPE PSA is planning to launch one new vehicle per region, per brand and per year from 2018. To achieve this, it is deploying a targeted product strategy at global level, based on multi-brand and multi-region programmes.

2 From the 1960s to the Early 1990s

2.1 The 1960s

In the 1960s, automobile manufacturers developed, with their own teams, the first “in-house” CAD/CAM systems. Peugeot and Citroën, independent companies at that time, were both pioneers in the development of CAD applications for their particular industrial needs. Individuals, such as Paul de Casteljau at Citroën and Pierre Bézier at Renault, associated with Peugeot at that time, laid the mathematical foundations for the first representations of complex curves and surfaces such as those found in car body shapes.

Also in the 1960s, CNC machines started to be used in the manufacturing plants of automobile manufacturers. Tool movement instructions for these machines were cal- culated using programs that modelled elementary geometric shapes: planes, circles, cylinders, etc.

2.2 The 1970s

The approach of using “in-house” CAD/CAM systems continued into the 1970s. However, at the end of the 1970s, GROUPE PSA, created by Peugeot’s successive takeovers of Citroën (1975) and Chrysler’s European subsidiaries (1978), selected Computervision’s CADDS software and developed a close partnership with this CAD system vendor. GROUPE PSA teams developed modules that were integrated into the systems developed, perfected and distributed by Computervision.

In parallel, GROUPE PSA developed internally a common information system, called SCE, to support, in a homogeneous and identical way, the development activi- ties of its three design offices (Peugeot, Citroën, and ex-Chrysler). This development was intended to facilitate economies of scale by making it easier to implement the components common to the Group (engines and gearboxes) and to standardise rela- tions with the Group’s suppliers’ network, the supply chain. The system included use of a common vehicle coding system (LCDV) throughout the Group based on a


common dictionary of attributes ranging from marketing to after-sales, engineering, manufacturing and commercial distribution with 2 coherent formats:

• A 32 bit fixed format from the Renault Peugeot partnership,
• Avariablelengthformatcombiningacommonrootandavariablelistofattributes

(technical and commercial).

The SCE Common Information System managed the design BOM, product-related drawings, and the status of information for the Methods (also known as Manu- facturing Engineering), Purchasing, Manufacturing and After-Sales teams. It also introduced the “Notice of Dissemination of Information” authorising creation and modification of a document.

The reference document at this time was the drawing. Sometimes it would be made manually on a drawing board, sometimes it would be output from a CAD system.

2.3 The 1980s

In the early 1980s, the Group started to use, as soon as it became available, the CATIA CAD system developed by Dassault Systèmes, distributed by IBM.

Use of the two CAD systems (CADDS and CATIA) was organised and specialised according to the type of part: CADDS for bodywork parts, CATIA for mechanical parts, powertrain and suspensions.

2.4 The Early 1990s

During the 1990s, both CADDS and CATIA were used. From the first years of the decade, syntheses of the areas where design was critical (in particular the engine compartment) were carried out using CATIA-based systems developed by GROUPE PSA’s internal teams.

To design a complex product, such as an automobile, one of the objectives is to make these critical technical areas, such as the engine compartment, very compact. The best use of the available volume traditionally required the production of phys- ical models in order to verify the consistency of the definitions of the volumes of neighbouring parts, the absence of interference between them, to assess the ease of assembly operations on the assembly line, and to ensure after-sales accessibility to components that might require intervention.

The costly cycle of design, part production and verification was repeated until consistent part definitions were obtained.

In the 1990s, it became possible, building on CAD models of parts, to assemble a Digital Model of a specific volume of the car, the Digital Mock-Up (DMU). With the

32 J.-J. Urban-Galindo and S. Ripailles

DMU, designers of the mechanical and bodywork parts of a vehicle project could see representations of neighbouring parts and take into account their virtual presence, thus avoiding interference from the very beginning of the design process.

As their work progressed, designers saved their CAD models in a database reserved for the “vehicle” project. The team responsible for the “vehicle synthesis” managed, on the basis of these still partial definitions, regular reviews, area by area, in order to ensure the compatibility of the designs of the various parts. This eliminated a large number of physical models compared to the previous process, resulting in substantial cost savings and, increasingly, a reduction in the time required to develop new products.

These digital models were also the data source for performing, with finite element models, calculations to predict and evaluate the behaviour of future vehicles. This made it possible to considerably reduce the number of physical prototypes that would be required to verify compliance with the safety standards in force. At GROUPE PSA, the first applications of this approach began in the early 1990s. They were adopted on a massive scale, but with software that was still in its infancy, for the development of the Peugeot 206 in 1995/96.

2.5 Lessons Learned and Recommendations

Before Peugeot’s acquisitions of Citroën in 1976 and Chrysler Europe in 1978, the 3 independent companies each had their own organisations, processes, “cultures”, information systems, and coding systems.

The strategic ambition of achieving sales volumes that would ensure the Group’s profitability by sharing parts and components was fortunately quickly accompanied by the establishment of a common purchasing department and the development of a common information system, SCE, to bring together the research departments around common processes, while maintaining their management autonomy.

In this phase, CAD was still limited and provided mainly 2D model drawings.

The SCE system, developed in partnership with the IT departments of the 3 com- panies, made it possible on one hand to share a common process model with config- uration management based on unified rules. On the other hand, it made it possible to establish common coding rules both for parts, and which was more complicated, for car configurations taking into account technical and commercial diversity. This LCDV coding ensured the one-to-one correspondence between the 2 representa- tion modes: a fixed format coding and a variable format coding in order to ensure compatibility with the “downstream” applications of each company.

The sharing between the 3 cultures made it possible to take advantage of each other’s progress and to question inefficient ways of working, in order to improve them.

The robust base thus built allowed the development of the following steps.

Following the first common application, SCE, all the applications of the 3 pro- duction companies (product structures, BOMs, routings, supplies, production man-


agement) and commercial distribution companies were able to take into account this reference framework in order to ensure consistency from marketing to after-sales.

They were then gradually unified up to 1995.

3 The INGENUM Project (1998–2004)

As the year 2000 approached, a redesign of product design processes was required in response to the need for increasingly shorter development times (time to mar- ket) requiring simultaneous (or concurrent) product and process design. It was also necessary to take advantage of the new organisation set up by the grouping of the Research and Methods Departments in the early 1990s.

The progress made with the Digital Model led to company management initiating a program to generalise this technology to all development programs.

At this time, software vendors were beginning to offer mature solutions for man- aging all design data (PDM systems) and, at the same time, the continuous progress in computing power and high-speed data transmission network technologies was being confirmed day by day, opening up new medium-term prospects for the organ- isation of engineering teams. In order to promote the desired evolution of operating methods, the strategic priority was to share data.

Also at this time, questions were raised about the Group’s CAD system choices. Conversions of part models designed with geometric modellers from different soft- ware vendors raised operational difficulties. It was finally decided to replace the CADDS geometric modeller, then used for bodywork parts design, by CATIA and to build the Digital Model management application using ENOVIA/VPM, also from Dassault Systèmes.

The SCE application, mainly focused on the drawing object and unsuitable for managing the multiple intermediate states of definitions (the “in-process” data), required a redesign to take into account the progressive convergence of solutions.

Moreover, commercial choices were being limited by a too-close link with the technical choices: technical authorisations were administratively necessary to modify commercial offers (pack options for example). This slowed things down and required unnecessary work.

The time had come for a major revision after more than 15 years of good and loyal service. A review of the data model, based on components, elementary products was necessary.

As it was seen that the DMU required both CAD models and parts lists, elements of the eBOM, it was decided to build the DMU based on the eBOM, itself built progressively. The progress of the project is then represented by Fig. 1.

The combination of these ambitions gave birth to a project, called INGENUM, officially launched in January 1998.

After a few months of consultation, the development plan was drawn up. It pro- vided for a gradual implementation in 3 defined stages, taking into account both the maturity of the software solutions on the market and the expected gains in...

Fig 1. The DMU development needs CAD models and part-lists

Fig 1. Some milestones in the progress of digital technologies in the 1990s

...improving the operational efficiency of the engineering teams. IT architecture choices were oriented towards the implementation of solutions based on increasingly powerful software packages, available or under development (Fig. 2).

Defined in the first months of 1998, the plan would be implemented throughout the period 1998–2004. Conceived as a coherent whole, its implementation phases were progressive steps.

3.1 Deployment of the Digital Model

The first step in the INGENUM project was the deployment of the Digital Model in the Extended Enterprise. It aimed to generalise to all projects, and to the entire car, practices that had been gradually implemented on individual projects.

The objectives of this step were to, on one hand, implement CATIA for bodywork development to replace CADDS, and on the other hand, deploy the Digital Model under the control of ENOVIA/VPM to facilitate data sharing.

To improve collaboration in the Extended Enterprise two features were provided to designers. Firstly, “CAD conference” sessions that allowed remote sharing, through high-speed networks, of analysis of the design of a part by geographically distant participants. Secondly, remote consultation of the GROUPE PSA digital model by authorised suppliers via a secure ENX (European Network eXchange) network.

By positioning the Digital Model at the centre of the project, at the heart of the detailed vehicle design, significant changes in operating modes were made.

3.2 Digital Factories

The second major theme was the implementation of the Digital Factories.
The ever-increasing performance of digital systems, hardware and software, which made it possible to visualise increasingly large sets of parts, paved the way for new

fields of application for these technologies, those of manufacturing process design. The aim was to set up digital representation systems to simulate processes, opti- mise them even before they were put into service in the workshops and, finally, record the data describing the processes in the global reference framework defining

the product and its manufacturing processes.
This activity, traditionally carried out by the “Methods” departments, was essential

to ensure the efficiency of production and the regular quality of high technology goods produced in large series. It had to be conducted simultaneously with the design of the product itself if the required level of performance was to be achieved on the Function-Quality-Costs triptych.

The investments involved in designing and building the tools for a “new vehicle” project or a new engine family are considerable; they represent a very significant part of the budget of these projects.

The prospects for savings in this area of expenditure, the gain in the time required to set up—running-in and ramp-up—the shop floor justify the development and implementation of specific systems in industries such as the automotive industry, where investments are sizable.

The main activities concerned were foundry, forging, machining and assembly of components, stamping, bodywork welding, painting and final assembly of the vehicle.

36 J.-J. Urban-Galindo and S. Ripailles

IT systems referred to as “Digital Factory” offer functionalities that make it pos- sible to do each job better; they make it possible to better:

  • Define all the elementary tasks making up the routings, sequences and groups on the workstations that will allow the product to be manufactured as defined by the design office

  • Calculate the successive stages of part machining, the trajectories of welding, painting and heavy part handling robots

  • Represent the shop floor in three dimensions, distribute the workstations, check accessibility and judge the ergonomics of the actions required of the operators.

    At the beginning of the millennium, few such solutions were proposed by software vendors because the market prospects were limited to very large industrial companies; they did not justify sufficient investment in research and development especially as the various companies had different needs and limited further this emerging market.

    Finally, systems to facilitate the accomplishment of a particular task, often coupled with office automation systems such as Excel, existed and were easy to use. Their integration into a more structured system, more demanding in data management, was difficult.

    GROUPE PSA decided to make progress, business by business, constantly keep- ing in mind the objective of integrating elementary data into the same global infor- mation system model in order to ensure a permanent overview of the state of product definitions and manufacturing processes.

3.3 Progressive Reference for Product and Process Description

The third major theme was the implementation of a Progressive Reference for Product and Process Description.

In line with the development of the Group’s strategy, which, since the early 1980s, had set up a common information system to support its engineering activities (even though the Group’s structure was still made up of three companies—Peugeot, Cit- roën and the former Chrysler subsidiaries renamed Talbot—each with its own R&D Department and Methods Department), the aim was to put in place a new generation of applications.

This new engineering support information system was to:

  • take into account organisational changes such as the regrouping of the R&D and Methods Departments and the increasingly important role of suppliers in design

  • encourage new working methods that had developed: strengthening the “project” organisation, simultaneous product-process design

  • integrate the digital systems that had invaded the design and method offices

  • limit internal developments by taking advantage of software packages that, by now, covered very wide areas, including for companies the size of GROUPE PSA


In addition, it was necessary to ensure continuity of the articulation with production management, commercial vehicle distribution, purchasing management and costing applications.

The overall architecture of this structure, its backbone, was based in particular on the shared description of the products (cars and the parts that they are made from), each function being able to build its applications according to its particular needs.

The central role of the data repository was key to the architecture of the project. Its implementation provided an opportunity to revise some points that required data improvements, such as a more precise identification of successive versions of part def- initions during the prototype development phases, as well as the decoupling between the rules governing the association of technical variants and those guiding the choice of options in the commercial offer.

3.4 Resulting Changes

In the mid-1980s, the number of CAD stations in the Group was in the order of a few hundred; ten years later, in the mid-1990s, thousands of stations were installed in GROUPE PSA’s design offices.

The shift to 3D design transformed the role of the drawing. It is still the official document proving intellectual property; it defines all the elements necessary for the manufacture and inspection of parts that comply with specifications, including tolerances on production dimensions. It brings the design activity to an end, but this activity was essentially based on 3D geometric models, gradually refined from a first sketch of the envisaged external shapes.

Successive iterations of the design at the various stages of the project, i.e. proto- type, pre-production and production vehicles, generate multiple versions of digital models that must be carefully identified and stored in order to be found without error.

The implementation of a robust information system for describing the composition of vehicles in terms of component parts, Bills of Materials, and documents describing them, drawings, calculation notes, allowing easy searches for technicians, is essential if this system is to become a strict reflection of the reality of the design office’s activity and replace the too many manually managed tables in office automation systems that became widespread, sometimes to compensate for the shortcomings of the structured applications in place.

The digital design systems that, until this time, had mainly improved the individual performance of the participants, were now leading the Group into a phase where progress was focused on the efficiency of the joint work of a guided team, motivated by a shared objective.

This approach could only succeed with intensive data and information sharing; advances in digital technologies now made this possible. The approach presupposes that everyone will accept, for the collective good, the view and criticism of others in the early stages of their work, when the options that determine quality and costs are decided.

38 J.-J. Urban-Galindo and S. Ripailles

The systematic implementation of these new operating modes highlighted the limits of the numerical representativeness of flexible parts such as electrical harnesses or part envelopes in their movements such as those that make up the exhaust line.

It also became clear that there was a need for greater rigour in the management of the interfaces between the vehicle’s equipment and its structure, which, on a small car number about 200, and in the need for better coordination between CAD and Bill of Materials management.

3.5 Results Achieved

The expected improvements in the physical assembly time of prototypes thanks to the early detection, by numerical analysis, of interference between adjacent parts with incompatible definitions were confirmed: a saving of three weeks on a phase that previously lasted seventeen weeks was thus achieved.

Over the thirty years from the 1970s, the distribution of roles between OEMs and their suppliers changed considerably. Suppliers were initially confined to the manufacture of parts entirely defined by the OEM’s design office, the slow circulation of information making it difficult to take supplier opinions into account regarding production difficulties. The scope for optimising solutions through more efficient product-process design remained very broad. Gradually, a few suppliers started to participate in the design of certain functions; they became real specialists. At the beginning of the 1990s, with the advent of the “project platform”, key suppliers sent representatives to join the OEM’s engineering teams. They could thus participate in the evaluation of solutions and guide choices in order to improve the quality/price ratio.

3.5.1 Modular Product Structure

Since 1998, the Group’s strategy has focused most of its commercial offer on a limited number of three platforms for small, medium and large vehicles. They bring together the elements of the structure and the parts not seen by customers in order to reduce design costs and increase the quantities produced, thus reducing unit costs.

The multiple silhouettes of the Peugeot and Citroën brands are developed on these platforms.

This strategy has strengthened the requirement for a modular description of vehicle ranges and reinforced the need for stricter coordination of the development and production of vehicles.

Like other car manufacturers, GROUPE PSA has built its product structures in a modular way combining a technical configurator and sub-assemblies, the combina- tion of which ultimately constitutes the single vehicle desired.


The vehicle coding consists of a series of codes, the technical configurator defines the combinations of options accepted in the line, the commercial options presented to customers but also the underlying technical characteristics imposed.

The manufacturing and commercial distribution information systems are built on the same vehicle definition code. The commercial configurator, which presents the product offer to customers, is a subset of the technical configurator.

3.5.2 ISO 10303 “STEP” Application Protocol AP214

The STEP AP214 standard defines a global data model to take into account the specificities of the automotive industry such as the diversity of a product group, the description of manufacturing and assembly processes, and the process plans.

This data model answers the recurring question that all manufacturers ask them- selves: “Can we define a single product structure for all the company’s needs”? It concludes that uniqueness is not a satisfactory answer and that at least two views are needed.

A “design” view, most often structured by following a functional division into systems and subsystems according to the product axis, and a “manufacturing” view, which gradually assembles physical sub-assemblies, in an order dictated by the fea- sibility of shop floor operations. This “manufacturing” view is multiple when the product is manufactured on several sites, an adaptation of the systems to the speci- ficities of the site and production rates may be necessary.

Multiple views of the same product must of course describe the same composi- tion, without error. Only a global, integrated model can achieve this result without excessive efforts of comparison and resynchronisation.

This model, which is close to the logical data structures in place in GROUPE PSA systems, was on the right track to stabilise in the mid-1990s.

In July 1997, GROUPE PSA took the strategic decision to choose it as a reference for the description of its products in all its new information systems developments.

The search for a software package that would meet GROUPE PSA’s needs was organised around specifications submitted to the main vendors in 1998. It was based on the STEP AP214 data model, which it was hoped would guide software developers in their own development plans.

SAP met GROUPE PSA’s specifications with a software package developed at the request of the Volkswagen Group, iPPE (integrated Product & Process Engineering). A detailed analysis showed that the “business objects” on which GROUPE PSA’s design processes were organised were satisfactorily represented in this software.

Able to manage distinct—but consistent—structures between design and man- ufacturing needs, iPPE could handle the diversity of the Group’s products. It was chosen as the backbone for future systems, the foundation of “configuration man- agement”.

Interoperability with digital representation systems was built using the AP214 model as a guide.

40 J.-J. Urban-Galindo and S. Ripailles

Evolution of ENOVIA VPM was specified by GROUPE PSA teams to improve its diversity management functionalities in accordance with the AP214 model. The coupling between digital model and product structures was thus made relatively easy.

3.5.3 Changes to the Development Process

The choice of SAP to implement the new information system was not neutral in the rules to be respected for its proper use. Reflecting the “Germanic” culture of its designers, data control is strict, updating responsibilities are clearly defined, and planned procedures must be strictly followed. Circumvention is risky and the con- sequences of deviations from the rules can be serious.

After having assessed the coherence of the edifice that this software package represents, it was quickly decided to avoid any modification of the product’s technical data model by aligning with the only possibilities available through its “parametrics”. The only specific developments allowed were to improve the presentation of some screens in order to facilitate access to reference data by authorised users, in as intuitive and easy a way as possible.

GROUPE PSA also reviewed in depth management rules, and clarified the respon- sibilities of the participants, and removed the ambiguities that had gradually crept into practices due to some particular exceptional events.

The fundamental reflection on the importance of sharing quality information, representative of the reality of activities, in an area of the company where initiative and imagination are encouraged, sometimes in opposition to a certain discipline, has had beneficial consequences.

The elimination of many special cases with poor justification has simplified pro- cedures.

The formal recording in the system of everyone’s decisions has led to a better understanding of the scope and actions of each of the participants, and to solidarity in obtaining the final result.

The essential role of the “Technical Management” professions, responsible for updating product structures, has been rediscovered. They were previously perceived as “administrative”, but were re-positioned and have become major players in the management of the collective act of design.

The requirement for data quality as soon as it is entered into new applications is no longer discussed.

Finally, control of the product’s components throughout its life cycle, “Config- uration Management”, has been reinforced by confirming the responsibility of the designers of the parts supported from the earliest stages by the Configuration spe- cialists. A new design maturity and validation process incorporating these changes was implemented.


3.5.4 Consequences for Related Applications

During this period, several other applications were being developed under the SAP software package. They were highly dependent on the structural choices made in the INGENUM project. They included a new application for managing the production of prototype and pre-series vehicles and the complete overhaul of the purchasing management application, which was initially developed in the early 1980s to support the merger of the purchasing departments of the three companies making up the Group.

These major applications were built using the product definitions set up by the INGENUM project, in particular the “articles” reference frame and the components and structures of the vehicles to be assembled.

The initialisation of the data in the application supporting the purchasing activity was the occasion for a strict overhaul of their quality, a “cleaning” which, although it seemed a little onerous at the time, was finally extremely beneficial; it allowed the application to start under the right conditions.

3.6 Lessons Learned and Recommendations

With the development of 3D CAD and digital mock-up, the development of simul- taneous product/process engineering and offline robot programming, the SCE appli- cation reached its limits.

The full integration of CAD into the process provided the opportunity to consis- tently address the configuration management of all digital models.

This led to improved tracking of part versions in the validation phases by inte- grating prototype manufacturing with fast evolving definitions in the development phases.

Configuration Management was refined by involving BOM Managers upstream, as soon as the need for a new part was decided. Reviews of digital models were based on the eBOMs, ensuring simultaneously the geometric development and quality of BOM expressions with all the complexity of variant combinations.

The “backbone” reference framework also ensured the correct creation of mBOMs and routing descriptions.

The evolution of commercial offerings in each specific market required much more flexibility—while staying within the limits of the authorised technical combi- nations. Vehicle descriptions were improved by better articulating technical options and commercial choices while ensuring their consistency.

The processes and tools put in place were ready for a new wave of progress that was already being felt: electronics and embedded computing, as well as further evolution towards approaches based on system engineering, the first steps of which had been implemented in 2000.

4 The COMPANY PLM Project (2012–2020)

The objective of the INGENUM project was to set up a progressive reference frame for product and process definition based on a single physical digital model for all developers. This project ended in 2004.

In 2012, GROUPE PSA launched the COMPANY PLM project (Fig. 3). Its objec- tive is to integrate all data related to the design, manufacture and maintenance of automotive products in a common corporate repository for all participants.

4.1 Improvement Drivers

This project integrates several principles already set out in the framework of LEAN PRODUCT DEVELOPMENT:

  • The efficiency sought is above all collective (efficiency is by no means the sum of all local performances) and is reflected in processes and a set of deliverables common to all participants.

  • Efficiency is about using as little energy as possible to provide a deliverable. The ideal is to no longer create what already exists (we are talking about CARRY OVER).

  • Efficiency then consists in “equipping” these processes in a single working envi- ronment that allows each participant to have the information they need (without risk of error and waste of time) to make their deliverables available. This principle can be illustrated by the concept of SINGLE SOURCE OF TRUTH.

Finally, these principles must respect and integrate the fundamental needs that are:

• Protection of the company’s information and intellectual capital
• Integration of the Extended Enterprise (the company, its suppliers and partners)• The ability to justify the validity of one’s choices at any time.

In short, to equip on the same platform all the processes of creation, and then con- figuration management, of product-related data over the entire life cycle, a strategic challenge for any company.

4.2 GROUPE PSA’s Ambitions and the Roadmap

The INGENUM and COMPANY PLM transformation projects responded to this logic of progress with the implementation of, first PDM, and then PLM.

This evolution has accompanied that of the automotive product and its ecosystem in the 21st Century:

  • A certain complexification of the product (low emissive powertrain, autonomy and assistance, mobility profiles and interaction with the environment) which requires a functional and systemic design of the product in its environment.

  • A competitive environment that requires rapid availability of innovations and, therefore, acceleration of product design and launch processes.

  • A consumer and legal framework that imposes traceability and justification of design (from systemic requirements to physical components).

  • A globalisation of the company and its network that makes it necessary to set up a secure platform accessible to the Extended Enterprise.

    The four main ambitions of the COMPANY PLM project are as follows.
    The first ambition is to work together and efficiently (between the different dis-

    ciplines, with JVs and suppliers).

  • Organise and structure all design documentation as a full and linked flow of data (functional, geometric, electrical, electronic, component, component, validation data, etc.)

  • Ensure their uniqueness and (secure) availability to all internal and external par- ticipants.

    The second ambition is to apply rigorous configuration management to drastically limit the number and cost of changes:

  • Link, trace and version data sets throughout their life cycle and in their context of use.

  • Carry out a reliable analysis of the overall coherence and impacts in the event of evolution or modification.

44 J.-J. Urban-Galindo and S. Ripailles

• Automate and secure the process of managing changes in development projects and in mass production.

The third ambition is to deploy System Engineering widely, integrating modular policy and promoting reuse:

  • Define and equip the creation and management of structures (requirements, func- tional, technical and industrial architecture) and the links that unite them, through to the integration and validation plan.

  • Deploy working methods based on the use of generic and already existing solutions offered to users.

    The fourth ambition is to put in place a fair and efficient monitoring system to manage projects and help take decisions:

  • Generalise the management of data maturity and the management by deliverables.

  • Automate the creation of dashboards based on unique, reliable, referenced and

    accessible information.

  • Implement analysis and intelligence applications around the data.

  • In view of the importance of the systems and their consistency (completeness of

    the data model), the COMPANY PLM project (following the INGENUM project) was conducted as part of a strategic partnership with Dassault Systèmes.

4.3 The Scope

The scope covered by COMPANY PLM includes all the processes and deliverables of R&D (Fig. 4).

The PLM platform covers (based on a single data model):

  • Project management processes and purchasing relationship management

  • The transversal process of management of release, change and impact analysis

  • The processes of system design and then functional, electrical, electronic and

    physical architecture

  • Construction processes and BOM management (configuration and diversity)

  • The processes of design of the manufacturing process, after-sales and manufac-


  • Management processes and integration of suppliers and partners.

    Its global architecture (Fig. 5) is based on a backbone logic ensuring the integration of business applications and the link with operating systems (including the company’s ERP system).

Fig 4. Scope of COMPANY PLM

Fig 5. Global Architecture

4.4 The Working Method

The working method for defining and implementing the company’s PLM solution respects the principles of LEAN and above all the fact that a project of this type is above all a change project.

This mode of work can be summarised as follows:

  • Make an assessment of the existing situation (processes, applications) in order to identify pain points, gaps and breakdowns.

  • Based on this assessment, build a “want to be” around processes and deliverables and position the expected gains.

  • Formalise the processes and deliverables from “want to be”, and build a business model of the data that will be manipulated (what data, what behaviour, and what interactions).

  • Based on this redesign of processes and the business data model, start an “appli- cation development” activity in Agile mode and by process groups (including the system vendor partner).

  • Don’t wait until everything is finished to start applying the solution.

    In the end, and given the scope of the project, the implementation of COMPANY PLM is progressive (each new development project integrates an ever-increasing number of processes).

4.5 The Results

The results are measured using several Key Performance Indicators:

  • Deployment (all new projects started since June 2016 are in PLM) and number of users

  • Scope (number of processes included in PLM)

  • Stakeholder satisfaction (by survey and comparison with the initial situation)

  • Validationoftheresolutionofthepainpointsidentifiedduringtheinitialdiagnostic


  • Robustness of the associated deliverables, syntheses and analyses

    At this stage the available architecture is as follows (Fig. 6).
    The architecture is based on OOTB standard solutions. Some further solutions

    will become available after the R2019x release of the 3D Experience platform.
    The architecture covers all product-related processes. An extension is expected

    in 2019 for process design and simulation.
    The global PLM platform integrates, around a unique data model:

    – The requirement flow and system engineering following a standard Engineering Structure. The processes and deliverables are organized (in the PLM) respecting

Fig 6. Current Architecture

the 9 views method defined by CESAMES and implemented in the OOTB 3DS

platform. We are now talking about integrated functional mock-up (FMU).

  • –  A complete change in the way of managing the product based on the BOM defi-

    nition and no longer on the DMU.

  • –  A deliverable management that includes object life cycles and automates parts


  • –  A dedicated service that creates the KPI and carries out the analysis in order to

    help users in their day by day jobs.

    The solution is used by 7000 people (as of October 2018), and has been used on all the projects started by GROUPE PSA since mid-2016.

4.6 Lessons Learned and Recommendations

The first lesson focuses on engagement and complexity. The implementation of PLM is above all a strategic change project. It represents a major expense but above all it leads to a change in behaviour that requires management involvement and training. The implementation of PLM can only succeed if its definition (processes) is clear and shared (understood and requested) by business managers and others working in the product lifecycle.

The second lesson follows from the first.

  • Never automate a process before it is defined and shared.

  • The implementation of the functional architecture and the integration of require-

    ments management was pre-empted by a change project which had the mission to define the organisation, operating modes and the rules of the game.

48 J.-J. Urban-Galindo and S. Ripailles

The third lesson is the consequence of the first two. Such a project can only succeed if:

  • The entire company is convinced of its necessity

  • User support and training is managed as a prerequisite

  • The “automation” is only carried out when the processes are defined and validated

  • The value added to the collective is demonstrated in particular by syntheses, dash-

    boards, traceability and impact analyses available in real time

    And, last but not least, this kind of project must be deployed step by step (in coherent packages of processes) without waiting for everything to be defined. Every new project uses more PLM processes than the previous one.

4.7 Next Steps

The COMPANY PLM project plan is being maintained with the objective of integrat- ing as many business processes and deliverables as possible, and using applications based, for example, on artificial intelligence to automate or assist stakeholders in their quest for efficiency.

5 Lessons Learned

Like all major automotive manufacturers, GROUPE PSA has been using digital technologies to improve its performance since their introduction, but has always kept in mind that the purpose is not to have IT tools but to have clear business processes that are supported by good IT tools.

From the early days of CAD to the implementation of the latest software devel- oped by the most advanced software vendors, working methods have been regularly reviewed to improve the effectiveness of development teams.

The Group’s information systems have always been considered an essential part of the organisation and performance of its vital processes in an industry where fierce global competition requires the constant pursuit of collective efficiency or risk dis- appearing. This is why IT is omnipresent and must itself be at the level of the best, while being economical with all the resources committed.

The implementation of the latest generation of information systems offers a global architecture that is perfectly integrated into the company’s information system. It pro- vides thousands of engineering professionals with information support to coordinate their individual actions by synthesising design systems and devices to manage the composition of the major “dossier” that constitutes the documentation of an auto- motive project.

This investment effort—because it is one—in the information system and busi- ness process efficiency has largely contributed to the very significant reduction in the development time of a new vehicle, which is now almost 104 weeks (2 years), com- pared to 3 years at the end of the 1990s and 5 years a few decades ago. It also allows the company to integrate such new industrial challenges as complexity management, working in the extended enterprise, and functional modularity.

Acknowledgements We thank Gilles Le Borgne, VPR & D and Quality of GROUPE PSA, for his support in the development of this case study.


  1. Annualresults2017.GROUPEPSA,92563Rueil-Malmaison,France

  2. Stark J (2015) Product lifecycle management (volume 1): 21st century paradigm for product

    realisation. Springer International Publishing. ISBN 978-3-319-17439-6

  3. CESAMESINSTITUTComplexsystemmodel.

  4. Liker J (2006) The Toyota product development system. Productivity Press. ISBN 978-1563272820

Jean-Jacques Urban-Galindo is currently CEO of Urban-Galindo Conseil. Previously, he worked for 38 years in Information Technology for GROUPE PSA, retiring in 2005. In 1998 he was appointed Director of GROUPE PSA’s digital engineering projects, embracing product and process development. He was responsible for the deployment of the digital mock-up and imple- mentation of a new generation of information systems in the area of new vehicles and engine design. During his career at GROUPE PSA he had many different responsibilities. During his time in the Auto Division he was responsible for the development and support of manufacturing solu- tions within GROUPE PSA’s central IS Division. In this role, he unified the systems used across all the Group’s plants. He also managed central planning, defining system development priori- ties for all Group functions, and managed research and strategic planning activities in the area of new information technologies. Jean-Jacques has a degree in Engineering from France’s pres- tigious Arts et Métiers school and a diploma from the Institut d’Administration des Entreprises business school.

Serge Ripailles has been PLM Project Director for the COMPANY PLM project since 2012. He is a graduate of École Supérieure d’Électricité and experienced in manufacturing, engineering and project management.

Share this:

4th February


Latest Jobs

Architect, Windchill PLM

West Chester, PA, USA Competitive Permanent

Posted on behalf of

Johnson & Johnson

About the job Job DescriptionJohnson & Johnson Technology (JJT), the Enterprise Technology group supporting all business functions under Johnson & Johnson is currently recruiting for an Architect,...

PLM Analyst

Manhattan Beach, CA, USA Competitive Permanent

Posted on behalf of


About the job Description: Company Overview Fisker Inc. is a design led pioneering mobility technology company researching, developing and producing next generation electrically power...

Application Consultant - Data Management Solutions

Quakertown, PA, USA Competitive Permanent

Posted on behalf of

Synergis Engineering Design Solutions

About the job Synergis Technologies, the region’s leader in data management, engineering, architectural, civil and manufacturing design solutions is searching for an engineering professional who is...

Looking for people to join your team?

Advertise your role with Momentum PLM. Get Started 

Looking to become a contributor?

Submit an article to Momentum PLM.  Get Involved 

Our Contributors

See the minds behind Momentum PLM.  Learn More 

Meet the Vendors

Read up on the latest vendor updates  Learn More 

Get the latest PLM updates in your inbox

Subscribe to our newsletter

Email Address


This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

By submitting your email address and any other personal information on the website, you consent to it being collected, held, used and disclosed in accordance with our Privacy Policy.