Soutenance mémoire
Les priorités du Groupe
Début 2007, un vaste plan de mobilisation interne qui doit permettre au Groupe de retrouver rapidement les voies de la croissance et de la rentabilité baptisé CAP2010 (Convergence, Accélération, Produit) a été mis en place. Ce plan définit les urgences opérationnelles où les progrès doivent être accélérés, et qui sont la qualité, la réduction des coûts, le produit et l’internationalisation du Groupe.
Le sujet de ce mémoire est directement issu du volet de réduction des coûts de CAP2010 décliné à la logistique.
Depuis la mise en place du nouveau Directoire en 2009 et pour progresser, le Groupe s’est donné une visionpour les dix prochaines années, qui est sa représentation du futur tel qu’il le souhaite.
Cette vision est le moteur de la création de valeur économique et rendra le Groupe unique par rapport à ses concurrents.
Elle donne le cap, et permet de tirer le meilleur parti des grandes tendances du monde et de l’industrie automobile. Ce cap donné par la vision transforme les menaces en défis qui nous font grandir.
Elle nous aide à nous réinventer : la vision, par son ambition et son aspiration, nous oblige à sortir de notre zone de confort, à travailler différemment, à rechercher en équipe les solutions inaccessibles individuellement.
Elle nous rassemble: pour assurer la convergence de nos actions, il nous faut donner du sens aux actions quotidiennes aussi bien que stratégiques. Il faut mobiliser sur la vision, qui agit comme un aimant et canalise les énergies. La compréhension et le partage de la vision par tous, et la confiance dans les équipes permettront la délégation, l’autonomie, et donc le progrès de l’entreprise.
Cette vision est inscrite dans les gènes du Groupe,une communauté d’hommes et de femmes partageant des valeursde respect, de responsabilité, de progrès continuet d’audace, elle va être le moteur de notre changement
Elle est composée de 4 ambitions :
• Un coup d’avance sur les services et produitspour faire face à la pénurie de pétrole, aux défis de l’environnement et aux évolutions des modes de vie.
• Un Groupe global parce que, pour maintenir notre indépendance et assurer notre croissance et notre profitabilité, nous devons figurer dans le club des meilleurs constructeurs mondiaux, parce que l’essentiel de lacroissance du marché automobile mondial se fait dans les pays émergents : Chine, Amérique latine, Russie…
• Une référence en efficacité opérationnelle parce que notre savoir-faire, notre tradition de rigueur et de discipline, nos valeurs de cohésion sociale nous ont permis d’être une « référence en efficacité opérationnelle». Nous avons comblé ainsi l’écart qui nous séparait des meilleurs par le système d’excellence PSA et le changement associé de nos comportements.
• Un développement responsableparce que la passion de nos collaborateurs va de pair avec leur épanouissement personnel, et parce que les clients de demain exigent de l’entreprise une conduite toujours plus exemplaire.
Cette quatrième ambition, qui concerne chaque homme et chaque femme du Groupe, ainsi que l’entreprise citoyenne, est le socle des trois premières.
La Direction des Systèmes d’INformation au service de la logistique
L’entité SIFA
La DSIN intervient dans tous les secteurs d’activité du Groupe PSA Peugeot Citroën pour concevoir, développer et exploiter les Systèmes d’Information.
Les différentes logistiques du Groupe
Les missions de la logistique des FC (Flux Constituants) et de la logistique des FV (Flux Véhicules) sont assurées par la DPLOpour la DTI sur le périmètre des pièces « série ». La logistique des PR (Pièces de Rechange) est quant à elle assurée par la DSP pour la DM (Direction des Marques).
La logistique des Flux Constituants (FC)
La logistique des Flux Constituants est également appelée logistique amont. Elle est assurée par le service ILFC(Ingénierie Logistique Flux Constituants et systèmes) et intervient sur les flux amont de la sortie du process fournisseur à lalivraison en bord de ligne pour toutes les usines du Groupe (flux physique et flux d’information) et les flux avals de composants des usines de la DTI.
L’objectif de la logistique des FC est d’assurer la disponibilité des pièces auprès de l’opérateur en minimisant les coûts et en respectant la qualité [PSA001].
Les missions de ILFC
• de concevoir, industrialiser et mettre à disposition des usines les processus, référentiels, méthodes, moyens et outils pour atteindre le meilleur niveau de performance logistique, de sécurité et d’ergonomie,
• d’accroître la performance logistique des fournisseurs, notamment en développant le travail en partenariat,
• d’optimiser les flux de circulation physique des produits du fournisseur jusqu’au point de consommation au poste de fabrication en réduisant les surfaces et le temps d’écoulement,
• d’assurer la cohérence et l’efficacité (coût, qualité, délais, sécurité, ergonomie) des processus logistiques sur l’ensemble du périmètre (approvisionnement, logistique interne, stock, frais généraux) avec les CPL des usines,
• d’intégrer l’organisation du transport amont dans les processus d’approvisionnement pour en réduire les coûts et garantir l’efficacité globale avec le prestataire transport.
La logistique des Flux Véhicules (FV)
Cette partie de la logistique des Flux Véhicules (FV ) est appelée aussi logistique aval. Elle est assurée par le service ILFV (Ingénierie Logistique Flux Véhicules et systèmes).
La mission de ILFV est de définir, de développer et de mettre en œuvre les référentiels, processus, systèmes d’information, moyens et outils qui permettent de placer le Groupe au meilleur niveau de performance logistique pour les Flux Véhicules (coûts logistiques, qualité du flux logistique sur le flux VN (Véhicules Neufs), maitrise du délai de livraison annoncé au client) et le traitement des informations associées [PSA002].
Les activités de la logistique aval s’exercent en vie série, en liaison avec les projets industriels et les projets véhicules, ainsi qu’à l’occasion descoopérations avec des partenaires extérieurs.
Le domaine couvert est celui de la logistique véhicules qui va de la prévision de commandes jusqu’à la livraison des véhicules aux points de ventes, en prenant en compte le flux physique des véhicules dans les UT.
Le schéma de l’annexe 1 montre les logistiques amont et aval mis en œuvre par la DPLO dans le Groupe.
Le Protocole Logistique Electronique
La vocation du Protocole Logistique Electronique (PLE)est de proposer un support unique, accessible et consultable par tous les acteurs du flux, leur permettant la définition et les mises à jour des protocoles logistiques. Le PLE remplace un document papier lourd dans sa gestion et de fait peu diffusé. Il décrit les modalités d’enlèvement, de transport et de livraison des pièces entre le fournisseur, le transporteur et le client PSA . Le PLEest le référentiel du flux pour chacun de ces partenaires. Son principal apport est de proposer un processus d’automatisation de validation de protocole logistique grâce à un workflow de signature.
Des versions métiers organisées à partir de principes structurants
Le programme CORAIL concerne un très grand nombre d’acteurs internes et externes (5.000 personnes dans nos usines et plus de 10.000 chez les fournisseurs).
Afin de réduire la complexité du programme, il a été décidé de rythmer les engagements au travers de versions. Cela permet un engagement progressif et un lissage des charges
La définition et la validation des modes de fonctionnement se font à travers l’identification de principes structurants et leur présentation/validation lors des comités métiers. Une version CORAIL correspond donc à un ensemble fonctionnel reposantsur des principes structurants et des enjeux associés validés.
Une évolution des systèmes d’information
La prise en compte des nouveaux modes de fonctionnement et la réduction des capitaux employés passent par un meilleur traitement de l’information (remplacement du stock par de l’information vivante…). L’évolution de nos systèmes d’information est donc nécessaire et indispensable.
Les Systèmes d’Information supportant la logistiqueamont ont 25 ans d’âge, ils présentent des risques de perte d’intégrité et d’obsolescence technique et ne peuvent pas en l’état répondre aux nouvelles exigences.
Une rupture est nécessaire afin notamment de mettre en œuvre des fonctions de lissage, d’avoir la connaissance de l’encours, de gérer la LDE(Liste D’Enlèvement), de disposer d’un calcul d’approvisionnement pour les flux lointains … Cette rupture passe par la refonte des principales applications du domaine.
L’accostage entre PLE et CORAIL
Aujourd’hui, pour créer un protocole logistique, l’utilisateur se connecte à l’application PLE et créé le Corps du protocole, puis la CAT . Les informations des flux de pièces rattachés à ce protocole arrivent depuis l’application PEGASE (Planning Et Gestion des Approvisionnements SErie). Quand toutes les informations sont renseignées, le protocole suit un circuit de validation. Quand ce protocole est validé, il est transmis aux applications qui sont chargées de son exploitation.
Quand CORAIL sera opérationnel, dès sa première version, le mode opératoire sera le suivant : toutes les informations nécessaires à la création du protocole (Corps et CAT ) seront transmises à PLE par CORAIL , y compris les flux de pièces. Le protocole suivra alors le circuit de validation depuis PLE. Quand ce protocole est validé, il est transmis à CORAIL qui sera chargé de son exploitation ou de sa transmission vers les applications tierces.
Les versions suivantes de CORAIL reprendront au fur et à mesure d’autres fonctionnalités de PLEjusqu’à absorber complètement l’application.
Etude Préalable
Les deux premiers mois de mon stage m’ont permis de mener l’étude préalable du projet d’intégration des flux logistiques de la DSPdans PLE.
Pour y parvenir dans de bonnes conditions, nous avons d’abord fait un état des lieux de l’existant, tant du point de vue des outils utilisés jusqu’alors que du point de vue fonctionnel.
Puis nous avons procédé au recueil des besoins de la MOA , pour ensuite bien cadrer la solution. Enfin, nous avons analysé plus finement le code fournisseur pour bien isoler le principal point fonctionnel à résoudre. Nous avons ainsi pu cadrer le projet de réalisation de l’intégration des flux logistiques de la DSP en termes de fonctionnalités, coûts et planning.
L’environnement du projet
Outils utilisés pour l’application PLE
Logiciel de modélisation
Le logiciel utilisé jusqu’à présent pour modéliser l’application PLEet sa base de données est le logiciel PowerAMC dans sa version 6.1 (datant de1995), de l’éditeur Sybase [INT004].
Ce logiciel permet de travailler avec la méthode Merise. Ci-dessous une vue du modèle physique de données de PLE qui montre la table des Corps (ELPQTCOR) et ses relations avec la table des partenaires (ELPQTPAR, appelée aussi table des COFOR (COdes FOuRnisseurs) tel qu’il est représenté sous PowerAMC, avant les modifications pour la DSP.
L’inconvénient de ce logiciel est qu’il n’est plus distribué ni supporté dans cette version. De plus, il ne fait plus partie des logiciels préconisés dans le groupe pour la modélisation.
L’origine du projet
Notre projet reprend une partie de l’étude préalable initiale sur le sujet qui avait été lancé début 2008. Dans un contexte économique qui nécessitait alors de prioriser les sujets à instruire, il avait été décidé de mettre ce projet en sommeil et de le traiter dans le futur.
Une partie des phases de recueil du besoin et de cadrage des solutions présentées ici sont donc reprises de l’étude préalable initiale et ont été modifiées et complétées pour s’inscrire exactement dans le périmètre retenu aujourd’hui. L’étude préalable initiale est elle-même issue d’un programme plus vaste nommé « Prix Départ» qui signifie que le client PSA achète ses pièces au départ du fournisseur. Le vendeur a donc rempli son obligation quand la marchandise est disponible sur ses quais pour un enlèvement dans les délais et pour les quantités spécifiées. Le terme « Prix Départ » s’oppose au terme « Franco » qui signifie quant à lui que le coût et l’organisation du transport est à la charge du vendeur, ce coût logistique étant inclus dans le prix du produit.
Recueil des besoins
Notre projet reprend donc une partie du périmètre sur lequel avait été lancée l’étude préalable, notamment dans sa composante « Gestion du transportamont ». L’autre partie abordée lors de l’étude préalable initiale, à savoir la « Gestion de l’échéancier transport », ne fait pas partie du périmètre de ce projet puisqu’il sera directement repris dans la première version de CORAIL .
L’organisation logistique de la DSPest modifiée afin d’intégrer l’organisation et le pilotage du transport amont (qui désigne généralement le transport depuis le fournisseur jusqu’au site client) du fournisseur jusqu’aux magasins de pièces de rechange. C’est une évolution de l’incoterm qui permet le transfert de la responsabilité du transport. Le fait de modifier cet incotermpermettra à la DSP d’être responsable de l’organisation du transport amont, donc de pouvoir massifier les tournées de ramassage et donc les flux, c’est-à-dire d’optimiser le remplissage des moyens de transport (routier, ferroviaire, …) qui sont mis en œuvre.
Cette évolution s’inscrit dans le cadre des projets CAP2010, notamment dans sa partie concernant la réduction des coûts. En effet, les gains du coût de transport liés à la rationalisation des moyens ont été estimés à 1% de la masse du transport amont après initialisation de l’ensemble des flux de la DSP(de 90K€ pour 2010 à 480k€ en 2013). Il s’agit donc d’un projet stratégique qui est étroitement lié à l’objectif de réduction des coûts de logistique.
La logistique « série » fonctionne déjà en « Prix Départ » et décrit ses protocoles dans une application existante, l’application PLE. La DSP souhaite utiliser cette application. La mutualisation des flux entre la DSP et la DTI, au-delà de l’utilisation d’une application unique, permet d’avoir un seul vecteur d’entrée pour le fournisseur, de mutualiser les formations et les animations, de partager les mêmesmodes de fonctionnement.
Cette phase de recueil des besoins est aussi la phase durant laquelle les scénarios de recette utilisateur seront définis. Ces scénarios de recette ont pour objectif de faire valider par le métier le bon fonctionnement de l’application dans son contexte de travail ainsi que les jeux de données à utiliser. Ces scénarios reprennent les enchaînements des tâches (y compris les tâches non informatisées) de l’utilisateur pour réaliser son activité. Ils seront rajoutés aux scénarios de recette utilisateur de l’application PLE qui existent déjà.
Cadrage des solutions
Le besoin de la DSPest donc d’être responsable de l’organisation du transport amont.
L’objectif du cadrage des solutions est d’identifier les exigences fonctionnelles et non fonctionnelles qui sont liées à ce besoin. C’est également au cours de cette phase que sont finalisés les tests de recette utilisateur.
Exigences non fonctionnelles
Les exigences non fonctionnelles sont les mêmes que celles de l’application PLE. Il n’y a pas d’exigence non fonctionnelle nouvellement identifiée puisque les évolutions pour la DSP seront directement intégrées à PLE. Les exigences non fonctionnelles couvrent notamment les exigences en terme de disponibilité de l’application, de sauvegarde des données, de performance, de maintenance.
Traitements impactés
Les traitements existants sont en fait assez peu impactés. En effet, puisqu’il est possible d’avoir l’information de COFOR souhaité en passant par la table à double entrée, il devient aisé de faire appel à cette table pour tous les traitements qui sollicitent une information de COFOR. Ainsi l’impact sur les traitements est bien compris, bien maîtrisé et le risque d’avoir à subir des effets de bord est mineur.
Présentation des COFOR dans les écrans
L’impact au niveau des écrans est quant à lui plus vaste, puisque toutes les zones de saisie et les listes résultats qui contiennent l’information de COFOR sont à retoucher. Dans un premier temps, nous avons pensé à isoler les sites de la DTIet ceux de la DSPafin de présenter les résultats en fonction du site d’appartenance de l’utilisateur.
Après en avoir discuté avec les MOA concernés, DTI et DSP, il est apparu que le fait de montrer les trois informations de COFORpourrait également servir aux utilisateurs de la DTI, notamment pour les aider à dissocier le COFOR hybride en COFOR Vendeur / COFOR
Expéditeur. Effectivement, à l’horizon CORAIL , c’est cette double information qui sera utilisée en lieu et place du COFOR hybride qui sera abandonné. Cette démarche préparera l’accostage de PLEau projet CORAIL en préparant les utilisateurs au changement qui aura lieu à ce moment là.
De nombreuses IHM doivent donc être modifiées pour y intégrer les informations de COFOR Vendeur et de COFORExpéditeur en plus du COFORhybride. Ces informations vont venir s’ajouter à l’existant, d’une part parce que tel est le besoin des utilisateurs de la DSP et d’autre part pour ne pas perturber le mode de fonctionnement des utilisateurs de la DTI.
Les écrans à modifier comportent des similitudes : en effet, ils nécessitent tous la mise à disposition des informations de COFOR Vendeur et de COFOR Expéditeur en plus du COFOR hybride. Dans certains écrans, il est nécessaire de pouvoir saisir une partie de l’information à rechercher, dans d’autres ce n’est qu’une information à représenter. Au vu des ces divers modes de fonctionnement, nous avons décidé la création d’un composant unique qui sera chargé de recevoir la demande de l’utilisateur (saisie du COFORhybride ou saisie des COFOR Vendeur et COFOR Expéditeur) ou de lui restituer l’information sur les trois COFOR. Ce composant, en fonction de l’écran dans lequel il sera implémenté, sera modifiable ou non.
Techniquement, nous avons créé un tag JSP (Java Server Page) [INT008] que nous avons appelé « ple3Cofors », en fait une simple balise XML (eXtensible Markup Language) à laquelle est associée une classe Java qui sera chargée de l’implémentation du composant en fonction des paramètres qui lui seront donnés. Ces paramètres permettront de définir si les COFORpeuvent être saisis, s’il faut ou non rendre la saisie de la raison sociale du COFOR possible, etc. Ainsi nous pourrons construire notre composant de manière dynamique en faisant simplement appel au tag que nous avons créé et en lui passant les paramètres nécessaires à sa construction, en fonction du besoin dans l’IHM.
Modèle physique de données
Grâce à une fonctionnalité proposée par l’outil EA , nous avons mené une opération de rétro ingénierie sur la base de données de PLE. Cette opération nous permet de disposer dans EA d’un modèle physique complet et correspondant à ce qui est réellement utilisé en exploitation du point de vue de la base de données.
Nous avons complété ce modèle physique de données, en y ajoutant les éléments identifiés lors de la conception. Cela s’est traduit, notamment au niveau de la table des partenaires, par l’ajout des informations de COFOR Vendeur et de COFOR Expéditeur.
Les tests MOE
Intégration des composants
Après avoir testé chaque fonction, composant ou batch de manière unitaire, après s’être donc assuré qu’il n’y a pas de problème et que la fonction répond bien et fait ce pour quoi elle est prévue, il faut d’une part agréger ces fonctions ensemble, d’autre part intégrer l’ensemble de ces fonctions dans l’existant. Les tests d’intégration ont pour but de valider le fait que toutes les parties développées indépendamment fonctionnent bien ensemble de façon cohérente. Ils vont servir à la qualification au sens technique de notre application. Les tests fonctionnels vérifient que les fonctions sont bien atteintes, conformément aux contraintes définies dans les spécifications.
Pour vérifier la bonne intégration des données des COFOR issues des batchs, nous avons mis en place une journalisation systématique des problèmes potentiels rencontrés. En effet, jusqu’à présent PLE recevait les informations sur les COFOR depuis la BFP. Ce mode de fonctionnement reste inchangé, mais des informations supplémentaires arrivent depuis l’application RFR pour enrichir les informations déjà en base de données, notamment pour donner les COFOR Vendeur et COFOR Expéditeur composants le COFOR hybride.
Nous avons inscrit dans le journal d’exécution du batch tous les cas pour lesquels un COFOR hybride reçu depuis le fichier RFR ne trouve pas de correspondance dans la table des fournisseurs de PLE. Cette table est quant à elle alimentée en données depuis l’application BFP, elle devrait donc contenir à minima tous les COFOR hybrides connus. Grâce à cette journalisation des problèmes relevés, nous avons pu aligner l’ensemble des systèmes en remontant les cas identifiés dans les journaux d’exécution des batchs aux différentes personnes en charge des applications RFR et BFP, pour que des actions de correction ou de mise en cohérence des données soient mises en œuvre. Nous avons ainsi contribué à la démarche de convergence des référentiels du groupe, travail fastidieux mais nécessaire notamment dans le cadre de CORAIL .
Qualification technique
Cette qualification technique est la partie des tests qui sont destinés à vérifier le bon fonctionnement de l’application sur son environnement d’exploitation. Ces tests sont de la responsabilité de l’industrialisateur et sont tracés dans la matrice de traçabilité. Les tests d’industrialisation avec les tests incluant les procédures dégradées y sont menés. Durant ces tests de qualification, nous avons également testé le scénario de démarrage pour la montée de version de l’application sur la production. Ce scénario de démarrage donne le déroulement point par point de la mise en production de l’application. Il est joué d’abord en préproduction pour s’assurer que rien n’est oublié pour que la mise en production des évolutions se déroule de la meilleure façon possible.
Les tests MOA
Les tests de non-régression
Etape importante avant les tests utilisateurs, les tests de non-régression visent à s’assurer que les développements effectués n’ont pas introduit de défauts ou que des défauts ne sont pas découverts dans des parties non modifiées de l’application. En effet, rien ne garantit que la partie de l’application non modifiée n’ait pas été impactée par les modifications, c’est fréquemment le contraire qui se produit [PRA2009].
Ces tests sont fastidieux, car ils doivent être les plus exhaustifs possibles, afin d’assurer que l’application fonctionne toujours de la même manière. Or la nature du phénomène de régression impose de tester à nouveau un grand nombre de fonctionnalités, précédemment testées et validées, alors que les fonctionnalités récemment validées sont peu nombreuses.
Les tests de non-régression ont fait l’objet d’une collecte massive de tous les scénarios de tests existant pour PLE depuis ses débuts, en parcourant les nombreuses arborescences qui contenaient de la documentation sur l’application. Ces divers scénarios ont été regroupés au sein d’un même dossier, il nous permet ainsi de dérouler ces tests en se concentrant sur les tests et non sur leur collecte. Au total, quatre-vingt dix sept scénarios de tests de nonrégression sont ainsi déroulés pour les tests de non-régression. Ce nombre représente les tests déjà écrits pour l’application enrichis de la quinzaine de tests que nous avons créés spécifiquement pour cette version de l’application.
L’ensemble des tests de non-régression a été effectué de manière conjointe par la MOA et par la MOE, cela représente un cumul de trois jours de tests pour une personne. C’est toutefois nécessaire pour s’assurer qu’il n’y a pas eu d’impact malheureux dans les autres parties de l’application. Il devient alors évident que toute livraison ou correction de l’application qui intervient pendant ou après cette phase de tests nécessite de devoir les reprendre entièrement.
Un exemple de scénario de test de non-régression tel qu’il a été déroulé lors de ces tests est montré en annexe 6.
|
Table des matières
INTRODUCTION
PROBLEMATIQUE
1 CONTEXTE ET CADRAGE
1.1 LE GROUPE PSA PEUGEOT CITROËN
1.2 LA DIRECTION DES SYSTEMES D’INFORMATION AU SERVICE DE LA LOGISTIQUE
1.3 LES DIFFERENTES LOGISTIQUES DU GROUPE
1.4 LA TERMINOLOGIE LOGISTIQUE CHEZ PSA
1.5 LE PROTOCOLE LOGISTIQUE ELECTRONIQUE
1.6 LE PROJET CORAIL
1.7 L’ACCOSTAGE ENTRE PLEET CORAIL
1.8 LES OBJECTIFS DU STAGE ET DU MEMOIRE
2 ETUDE PREALABLE
2.1 L’ENVIRONNEMENT DU PROJET
2.2 L’ORIGINE DU PROJET
2.3 LE CODE FOURNISSEUR
2.4 LA STRATEGIE DE TESTS
2.5 L’ENGAGEMENT DES RESSOURCES
3 PROJET DE REALISATION
3.1 L’ANALYSE DU BESOIN
3.2 LES SOLUTIONS ENVISAGEABLES
3.3 LA CONCEPTION DE LA SOLUTION
3.4 LA REALISATION ET LES TESTS UNITAIRES
3.5 LES TESTS MOE
3.6 LES TESTS MOA
3.7 LA MISE EN PRODUCTION
4 PILOTAGE DU PROJET
4.1 LA DEMARCHE PROJET PSA
4.2 LES LIVRABLES DU PROJET
4.3 LA GESTION DE PLEAU QUOTIDIEN
5 APPORTS,PERSPECTIVES ET BILAN
5.1 LES APPORTS PERSONNELS
5.2 LES PERSPECTIVES FUTURES
5.3 LE BILAN DU PROJET
CONCLUSION
ANNEXES
GLOSSAIRE
BIBLIOGRAPHIE
LISTE DES FIGURES
LISTE DES TABLEAUX
TABLE DES MATIERES
Télécharger le rapport complet
