Understanding PLM System Concepts to Facilitate Its Implementation in SME: The Real Case Study of POULT

. In 2012, our research team in partnership with LASCOM (a French PLM software editor) proposed models and an approach to help SMEs when they decide to deploy PLM systems [1, 2]. Our approach was to use formalism based on mind maps to promote exchanges between customer/users and PLM editor. Objective was to facilitate definition of elements that have to be defined, modeled, evaluated and implemented in a software solution to make deployment process more effective. Different real case studies emphasized that our approach have to evolve to be more “customer” centered. In this paper we present one of these real case studies which is in progress. This research collaboration concerns POULT, a manufacturer of biscuits which decided to deploy a PLM solution in few months. We describe the adopted approach to analyze the users’ needs and draft the request for proposal which will be send to PLM editors.


Introduction
For SMEs, PLM system is a solution to manage all the processes and associated data generated by events and actions of various lifecycle agents (both human and software systems) and distributed along the product lifecycle phases, from the beginning to the end of life [3].SMEs have some difficulties in the use of PLM systems and do not exploit their full potentiality and a big amount of information and knowledge is being lost or requires a higher human effort to be preserved [4,5].The main problems for SMEs in the exploitation of a PLM system are the lack of models to represent the product lifecycle [5] and the approach used by PLM editor to adapt and deploy their solutions for SME [1].This approach is often iterative and incremental and based on models and prototypes (Figure . 1).It offers a bottom-up approach to analyze and model the decisional, functional and organizational structure of the customer but partially ensures consistency between the expectations/needs and the functional aspects of the PLM solution.Moreover, the number of iterations to define the users' expectations is too important and the capitalization of actors' feedback is not sufficiently taken into account.One problem stems from the uniqueness and the diversity of each solution.Other one concerns the fact that views and semantics between the different actors of the project are often different: customers/users are functional and business oriented, while the editor is faced with structural and technological issues.This often leads to a misunderstanding underlying and creates difficulties during the specifications validation step.

Fig. 1.
Iterative and incremental approach to deploy PLM solution [1].This approach is not efficient yet and causes significant delays on the initial planning.To reduce and optimize the analysis of expectations for each new project and to increase the efficiency of the procedure for solutions deployment we proposed to develop a new approach [1].Our objective was to facilitate the preliminary analysis of the system and the characterization of users' expectations and needs.This approach was developed with LASCOM a French PLM editor and was inevitably "editor oriented".In a nutshell, approach optimizes audit and analysis of need for PLM editor (time reduction) and creates a dependency relationship between customer and PLM editor.In this case, SMEs could be reluctant to approach PLM editors and prefer to keep a relative autonomy towards editors.SMEs need time to understand and integrate PLM system and are often suspicious about editors' intentions.To limit harmful effects of a too PLM editor centered approach we propose in this paper an process to enable companies to understand PLM concept, express their needs and define their own specifications in autonomy before calling a PLM editor.Our approach is composed with 4 steps in order to formalize the needs of the company before the first meetings with the PLM editor (figure 2): First step: understanding the organization of R&D process, to model the existing organization without considering a "PLM editor centered" vision, Second step: understanding the philosophy of PLM approach, to appreciate and estimate possible impacts of the PLM in the company, Third step: considering users in the PLM deployment, to favor acceptation, Fourth step: formalization of the needs and definition of the preliminary specifications of a solution which could be an adapted one for the company.

Expression of customer needs
(audit, analysis of need)  In this paper we present our approach through the real case study of Poult, a French producer of biscuits, which decided to improve its research and development process in 2014 and initiated a reflection on the opportunity to use a PLM system.This SME has ever had experiences with different PLM editors and preferred to preliminary work with our research team in order to anticipate and limit difficulties before send a request of proposal to PLM editors again.The paper is structured in order to show our progressive approach to help members of the team "PLM project" (managers of R&D, production, marketing, quality and purchasing departments, R&D assistant, Ms. PLO -PhD student).First section describes the initial vision of the R&D process to be improved.Second section shows how Poult progressively understands PLM concepts and adapts them.Following section presents work in progress which concerns a user centered approach to precisely specify users' needs.Finally, last section concludes and states futures works.

First step: understanding the organization of R&D process
Poult is a French producer of biscuits which decided to improve its research and development process in 2014.R&D process essentially concerns development of new product or evolution of an existing one.Product could be developed for Poult's label or for other customers' labels.Poult controls technical activities to create biscuits but has many difficulties to control and manage data generated during R&D activities.That the reason why managers decided to study the opportunity to deploy a PLM system in the company to allow data management and increase efficiency of R&D phases.As the R&D process was not really formalized first step of our collaboration concerned global identification and definition of principal activities of the R&D process.This process begins when customer sends specifications of the expected biscuit and finishes when the industrial production of the biscuit starts (Table 1).In first time, the vision is quite global because it is relatively unusual for Poult to express its R&D organization.

Second step: understanding the philosophy of PLM approach
Preliminary description of the R&D process (Table 1) is useful to partially understand R&D process but it has to evolve to be more operational with a view to a PLM system deployment.So, second step of our collaboration was to switch from a classical "activities" model to a "product lifecycle" model.As the main problem for SMEs in the exploitation of a PLM system is the lack of models to represent the product lifecycle [5], start of this step was not easy.Discussion with project team members leaded to guide our reflection on the use of ontologies to provide an answer to the need for a clear understanding of product lifecycles phases [6] and the need of system interoperability [7].Several ontologies [8] or researches [9] exist and have been presented to members of the project with a view to build a common semantic and a share understanding of model.These exchanges allow us to find an agreement and we decide to exploit Bruno et al.'s ontology and UML model [5].Bruno et al. developed in 2015 their reference ontology for PLM which clearly makes appear PLM concepts (Table 2) and relationships between each on them (white classes -Figure 3).POULT chooses to use this ontology because it is based on a serious analysis of existing ontologies and it is considered as understandable and well-adapted to the company thanks to the use of UML.
Our experience with POULT puts in evidence the difficulty to identify ontology and models to present PLM philosophy and concepts to people in charge of a PLM project in a company.Thanks to such an experience, we are working on an approach to define and select possible combinations (ontology + models) depending on the company context to express the philosophy of PLM approach.We will present our propositions in a future paper which will be focused on more conceptual aspects of our research.

Product
A generic term for whatever is produced by a process and serves a need or satisfies a want.

Customer
The reference person of a company that ordered a product.

Project
The term used by a company to indicate the collaboration with a customer for the developing of a product.Each project refers to one product and is connected with one customer.Product component One of the hardware, electronic or software that makes up a product.A component may be subdivided into other components, which combine into sub-assemblies and assemblies to define product.Each product can be made of several components, and the same component can be used by different products.

Material
The material of which a product or a product component is made of.

Physical characteristic
The physical characteristic of a product or product component.

Unit
The unit in which the Physical characteristic is measured.

Activity
An action executed during the product lifecycle of a specific product that can be univocally and unambiguously identified.

File
Electronic data managed and stored as a single object.

Document
A uniquely-identified block of information that can be composed by several files.

Tool
A software tool used to produce a file, for which the name and the version have to be specified.

Resource
An entity that is involved in the execution of an activity.A resource can be of two kinds: Person or Machine.

Role
The term used to define a specific set of skills and responsibilities associated with the employees of the company.
Thanks to Bruno et al.'s propositions we create a common vision of a PLM system between team project members and researchers.Moreover, such description of PLM concepts and ULM class diagram were very helpful for the team which has been able to define its own description of PLM concepts and UML class diagram adapted to Poult.All Bruno et al.'s classes have been conserved (or slightly evolved) and 10 new classes complete the UML class diagram to be closed to the Poult's reality.New classes represent particularity of Poult or food industry.Poult considers a product as a quadruplet [recipe + raw materials + ingredients + packaging] and data associated to this quadruplet are managed separately.So these classes appear in the new version of the diagram.Moreover, food industry has specific rules to ensure quality during all the production process for the final users.These rules oblige Poult to manage precisely specific data (machine characteristic, supplier characteristics, etc.).These classes also complete the UML diagram.Table 3 provides a description of these new classes and Figure 3 shows an UML class diagram of PLM adapted to Poult (added classes in grey).

Food-Processing (to complete Product)
R&D department could develop new product (i.e.new biscuits) or new food-processing.So, a class "Foodprocessing" has been created to clearly make appear these two kinds of production.

Production site (to complete Customer)
A product or a food-processing could be ordered by a customer or by Poult's production site.So, a class "Production site" has been created to make appear these two kinds of prime contractor.

Recipe and Recipe component (to complete Product component)
Poult's products are identified thanks to a "recipe" and a recipe is composed with components.That the reason why the class "product component" evolved to be "recipe" and "recipe component" classes.A product has only one recipe which can be made of several components, and the same component can be used by different products.

Raw Material and Ingredient (substitute material)
In food industry the term "raw material" is preferable to "material".Raw material can be made of several "ingredient".Combination of ingredients in a raw material is an important data to respect food regulations.

Packaging
Product is one or more biscuits plus a specific packaging.Poult manages its biscuit and its packaging separately so a specific class has been created for "packaging".Packaging characteristic The different characteristic of a packaging.

Supplier
In food industry, all components have to be controlled.One performance indicator to be controlled is "who supply the component"?"Supplier" and associated characteristics are important data to be managed by PLM.Machine characteristic Food industry rules oblige to manage data about machines used to produce biscuit.Objective is to ensure quality of the process on the whole for final users.So, Poult has to manage data associated to its machines.

Third step: considering users in the PLM deployment
The UML class diagram adapted to Poult shows how project team members have understood PLM.They evolve from a global vision of the R&D process of Poult to a more operational vision which integrates PLM concepts.Thanks to such representation architecture of PLM system appears.As deployment and implementation of an effective solution not only consists in selecting and installing software but also in obtaining the users acceptance, we have to focus now on final users of the PLM system.The understanding of user's needs and expectations is a critical phase for the deployment of such solutions.Nevertheless, much of the traditional research on software project management does not consider users' expectation correctly and neglects to ask project managers about their perspectives and ideas on how to manage projects [10].This crucial step depends on the ability to understand and consider users' expectations [11] and to analyze, co-ordinate and control the collaboration between the numerous users concerning by the project: strategic/tactical decision-makers, project managers, designers, experts from different disciplines and with different experiences, external partners, etc.The views and semantics between the different actors of the project are often different.Customers are functional and business oriented, while the editor is faced with structural and technological issues.This often leads to a misunderstanding underlying and creates difficulties during the specifications validation step.To reduce these difficulties, we developed in 2012 an "editor" oriented approach to facilitate exchanges between PLM editors and customers [1,2].Our objective was to make easier the preliminary analysis of the system and the characterization of users' expectations and needs.This approach is based on the use of mind map and persona to progressively define users' profiles and expectations.
When a project starts editor initializes a specific map for the customer (Figure 4).Enterprise modelling which regroups data concerning the customer (structural and functional organizations, actors implied in the project, etc.).This branch evolves and is more and more precise according to project evolution.Follow-up of the contributions allows project manager to have a trace of each action realized during the project.The aim of this branch is to be able to follow each evolution of the project in term of "who decided what?" Follow-up of the deliverables regroups all the documents which are produced during the project.This branch helps editor and customer to judge if the progress of the project according to the common deadlines fixed from the start of the project.Software applications definitions is the branch in which we fond all the versions of the software developed during the project.
Each actor of PLM editor which is involved in the project completes his part of the map.Information concerning customer and project lifecycle (activities and associated documents) are in the map and each steps of the software development are capitalized and reusable.Relationships exist between elements of branches to obtain a global and dynamic vision of the structure of the system.Such a simplified representation makes easier relationships between editor and customer [1].A map is associated to one project and to one customer.When the PLM is deployed it is easy to maintain solution because editor has customers' data in the map and an evolution of the map is quickly reverberated in the PLM system.Concerning Poult, we have organized interviews of each potential user since few weeks in order to complete the branch "enterprise modeling" (Figure 5).Interviews are in progress and the branch evolves.Other branches cannot be completed, they concern PLM editor and no one is selected yet.When team project members will estimate that they have a clear vision of PLM concepts, of their needs and of the specifications of the solution, they will formalize all of these data (step 4 -figure 2) and send a request for proposal to PLM editors.

Conclusion
Collaboration with LASCOM until 2012 allows us to develop a specific approach to model system in which a PLM solution has to be deployed.Aware about limits of this approach we confront since 2015 our propositions to the reality in a SME, Poult,

Fig. 2 .
Fig. 2. Internal process to study relevance of PLM solution deployment in a company.

Fig. 4 .
Fig. 4. Global architecture of a map dedicated to a customer.Four branches structure the map:Enterprise modelling which regroups data concerning the customer (structural and functional organizations, actors implied in the project, etc.).This branch evolves and is more and more precise according to project evolution.Follow-up of the contributions allows project manager to have a trace of each action realized during the project.The aim of this branch is to be able to follow each evolution of the project in term of "who decided what?" Follow-up of the deliverables regroups all the documents which are produced during the project.This branch helps editor and customer to judge if the progress of the project according to the common deadlines fixed from the start of the project.Software applications definitions is the branch in which we fond all the versions of the software developed during the project.

Fig. 5 .
Fig. 5. Preliminary description of the production site of Montauban.

Table 1 .
Preliminary description of the Poult's R&D process activities and tasks.