PLM at GROUPE PSA
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 performance 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.
KeywordsPLM eBOM mBOM DMU Digital Factory System engineering Configuration management Variant management
1 GROUPE PSA
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 €65.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 calculated 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 activities 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 relations 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,
A variable length format combining a common root and a variable list of attributes (technical and commercial).
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 physical 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 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 companies, made it possible on one hand to share a common process model with configuration 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 representation 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 production companies (product structures, BOMs, routings, supplies, production management) 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 market) 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 managing 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 organisation 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 software 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.
The combination of these ambitions gave birth to a project, called INGENUM, officially launched in January 1998.
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, optimise 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.
IT systems referred to as “Digital Factory” offer functionalities that make it possible 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.
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 keeping in mind the objective of integrating elementary data into the same global information 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, Citroë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
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 definitions 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. prototype, 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.
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 combination 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 themselves: “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 feasibility of shop floor operations. This “manufacturing” view is multiple when the product is manufactured on several sites, an adaptation of the systems to the specificities of the site and production rates may be necessary.
Multiple views of the same product must of course describe the same composition, 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 manufacturing needs, iPPE could handle the diversity of the Group’s products. It was chosen as the backbone for future systems, the foundation of “configuration management”.
Interoperability with digital representation systems was built using the AP214 model as a guide.
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 consequences 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 responsibilities 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 procedures.
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, “Configuration Management”, has been reinforced by confirming the responsibility of the designers of the parts supported from the earliest stages by the Configuration specialists. 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 simultaneous product/process engineering and offline robot programming, the SCE application reached its limits.
The full integration of CAD into the process provided the opportunity to consistently address the configuration management of all digital models.
This led to improved tracking of part versions in the validation phases by integrating 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 combinations. 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.
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 environment 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.
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.
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 first ambition is to work together and efficiently (between the different disciplines, 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 participants.
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.
Automate and secure the process of managing changes in development projects and in mass production.
Define and equip the creation and management of structures (requirements, functional, 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.
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 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 manufacturing
Management processes and integration of suppliers and partners.
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 “application 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.
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)
Validation of the resolution of the pain points identified during the initial diagnostic phase
Robustness of the associated deliverables, syntheses and analyses
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 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 definition and no longer on the DMU.
A deliverable management that includes object life cycles and automates parts release.
A dedicated service that creates the KPI and carries out the analysis in order to help users in their day by day jobs.
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 requirements management was pre-empted by a change project which had the mission to define the organisation, operating modes and the rules of the game.
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, dashboards, traceability and impact analyses available in real time
4.7 Next Steps
The COMPANY PLM project plan is being maintained with the objective of integrating 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 developed 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 disappearing. 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 provides 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 automotive project.
This investment effort—because it is one—in the information system and business 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), compared 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.
We thank Gilles Le Borgne, VP R&D and Quality of GROUPE PSA, for his support in the development of this case study.
- 1.Annual results 2017. GROUPE PSA, 92563 Rueil-Malmaison, FranceGoogle Scholar
- 2.Stark J (2015) Product lifecycle management (volume 1): 21st century paradigm for product realisation. Springer International Publishing. ISBN 978-3-319-17439-6Google Scholar
- 3.CESAMES INSTITUT Complex system model. http://www.cesames.net/
- 4.Liker J (2006) The Toyota product development system. Productivity Press. ISBN 978-1563272820Google Scholar
Open Access This chapter is licensed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license and indicate if changes were made.
The images or other third party material in this chapter are included in the chapter's Creative Commons license, unless indicated otherwise in a credit line to the material. If material is not included in the chapter's Creative Commons license and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder.