Le PLM, Gestion du cycle de vie de produit a pour objectif de centraliser les données projet et produit et d'automatiser les processus métiers.
L’implémentation d’un projet PLM passe par la formalisation du besoin métier qui sert à identifier les données à centraliser et à formaliser les processus métiers à implémenter. Ce processus de formalisation se fait par l’écriture d’un use case.
Nous verrons dans cet article comment rédiger un use case en phase de cadrage.
Qu'est ce qu'un PLM ?
Le PLM, acronyme de Product Lifecycle Management, est un outil qui sert à gérer et à optimiser le flux des données tout au long du cycle de vie d'un produit.
En savoir plus sur les fondamentaux du PLM.
Qui est impliqué dans un projet PLM ?
Un projet PLM est avant tout un projet de transformation métier.
Il nécessite donc une forte implication des métiers à tout niveau :
1) Le Top management
Pour donner l’impulsion au projet et montrer que le projet PLM est un projet stratégique visant une transformation en profondeur du métier et de l’amélioration de sa performance opérationnelle.
2) Le Management intermédiaire
Pour participer à l’amélioration de ces processus métiers qui sont au cœur de son activité et donc du fonctionnement de son entité et d’intégrer d’éventuels impacts organisationnels, comme une/un :
- Évolution de son organisation
- Changement de mission des membres de son entité
3) Les Utilisateurs métiers
Pour que les processus implémentés répondent à leur besoin opérationnel et soient acceptés lors de la phase de déploiement, car leur permettent d’améliorer leur efficacité collective.
Une des erreurs classiques des projets PLM est de considérer que c’est avant tout un projet à caractère informatique et donc de le confier principalement à des acteurs IT.
La formalisation des besoins métier PLM passe par la rédaction d'un use case
La formalisation des besoins métiers à implémenter dans un logiciel PLM, se fait à travers la rédaction de Use Cases.
Avant de rédiger ces use cases, il faut commencer par identifier, avec le Top Management, les domaines fonctionnels que l’on souhaite implémenter dans le logiciel.
Pour rappel, voici en infographie, les domaines fonctionnels qui peuvent être couvert par le logiciel en question :
Pour chaque domaine fonctionnel, le Top management devra nommer un product owner et des key users représentatifs des métiers mettant en œuvre ces processus.
Ces acteurs doivent être dédiés au système PLM et doivent avoir un niveau de disponibilité de l’ordre de 50% à 80%.
Il est impératif que le product owner et les key users soient des acteurs métiers et non des supports informatiques ou des représentants de l’IT.
On cherche à capter le besoin métier en termes de données à gérer et de processus métier à implémenter.
Enfin, pour couvrir le domaine fonctionnel dont ils ont la charge, le product owner et les key users vont devoir rédiger plusieurs use cases couvrant l’ensemble des besoins métiers du périmètre.
Voici le résumé en infographie :
Qu’est-ce qu’un Use Case ?
Un use case correspond à un besoin métier.
C’est un ensemble d’interactions ordonnancées entre plusieurs acteurs permettant à l’acteur principal de satisfaire un besoin métier en lui apportant une valeur ajoutée d’ensemble.
La formalisation des besoins métiers se fait lors de plusieurs ateliers avec un product owner et des key users accompagnés d’un animateur maitrisant la méthode.
Il faut généralement 3 ateliers :
- Un atelier pour l’écriture du draft
- Un atelier pour affiner le use case et préciser les points en suspens soulevés lors du premier atelier
- Un atelier pour la relecture et la validation finale
Pour rédiger un use case, je vous conseille d’utiliser dans un premier temps un traitement de texte type Word ou Excel.
Pourquoi ? L’objectif est de se focaliser sur la captation du besoin métier.
L’utilisation d’un outil non maitrisé par le product owner et les key users va avoir tendance à focaliser leur attention sur la mise en œuvre de cet outil et sur la forme plutôt que sur le fond des processus métiers.
Un outil de traitement de texte est un outil simple que tout le monde maitrise.
Checklist pour rédiger un use case
Voici les guidelines pour rédiger votre use case pour un projet PLM :
- Il doit être compréhensible par tout nouvel arrivant dans l’entité ne connaissant pas le domaine métier
- Il doit être exploitable par une solution architecte qui connait le logiciel, mais ne connait pas le métier
- Il faut éviter les jargons et acronymes ou les expliquer
- Il faut décrire uniquement le besoin métier et non la solution informatique actuelle ou future
- S'il décrit la solution informatique, il risque d’orienter le logiciel proposée par la Solution Architecte. On risque alors de réimplémenter le mode de fonctionnement et les fonctionnalités passés et donc de ne pas améliorer voir de dégrader la performance opérationnelle
Les 8 étapes de rédaction d’un use case
Voici les étapes de rédaction d'un use case qui permet de formaliser un projet PLM :
- Identifier la finalité métier du processus
- Identifier les acteurs du processus
- Identifier les livrables d’entrée/sortie du processus
- Définir le scénario nominal
- Identifier les déclencheurs des extensions du scénario nominal
- Identifier les peines du processus actuel
- Compléter avec les exigences
- Synthétiser le processus sous forme de diagramme
Voyons chaque étape une par une :
1) Identifier la finalité métier du processus
Le nom d’un Use Case correspond à un verbe à l’infinitif suivi d’un complément en se plaçant du point de vue de l’acteur.
Par exemple : Finaliser la conception détaillée d’une pièce mécanique
2) Identifier les acteurs du processus
Voici un exemple d'acteurs à définir :
Acteur Principal : Concepteur produit
Autres Acteurs : Concepteur process, Responsable produit/process
3) Identifier les livrables d’entrée/sortie du processus
Voici quelques exemples :
Livrables d’entrée :
- Structure produit
- Définition numérique des pièces
- Contraintes process (outillages, support de montage, ...)
- Règles de conception métiers
Livrables de sorties :
- Définition numérique d’une nouvelle pièce mécanique officialisée
Si possible, il faut récupérer un exemple de chaque livrable pour comprendre de quoi il s’agit et caractériser son type.
4) Définir le scénario nominal
Il s’agit de raconter l’histoire qui atteint l’objectif sans aucun obstacle.
On recherche à identifier les activités métiers au juste nécessaire.
Il est donc nécessaire de challenger le product owner et les key users sur chaque activité :
- Pourquoi fait-on cette activité ?
- Quelle est sa finalité ?
- Pourrait-on s’en passer ?
- Pourrait-on faire autrement ?
Attention le scénario nominal est le scénario couvrant 80% des cas rencontrés.
On recherche avant tout à optimiser le scénario nominal et non à traiter 100 % des cas, ce qui conduirait à complexifier notablement la solution pour un gain limité.
Les cas avec un taux de fréquence faible continueront à être traités de manière dérogatoire au cas par cas par les opérationnels, et ne doivent pas apparaitre dans le scénario nominal.
Ci-dessous un Exemple de scénario nominal :
Etape | Acteur | Description |
|---|---|---|
1 | Concepteur produit | Prépare son environnement de travail en remontant la zone avec les pièces environnante |
2 | Concepteur produit | Finalise la conception détaillée de la nouvelle pièce mécanique |
3 | Concepteur produit | Vérifie que les règles de conceptions métiers sont respectées |
4 | Concepteur process | Prépare son environnement de travail en remontant la zone avec des pièces et les contraintes process (outillage support montage ...) |
5 | Concepteur process | Vérifie la faisabilité process de la nouvelle pièce mécanique |
6 | Responsable produit/process | Mène une revue technique d’acceptation de la pièce avant officialisation |
7 | Concepteur produit | Officialise la nouvelle pièce mécanique |
5) Identifier les déclencheurs des extensions du scénario nominal
Un déclencheur correspond généralement à une activité de vérification.
Une fois qu’un déclencheur est identifié, on décrit sa prise en compte par une extension au scénario nominal :
Etape | Acteur | Description |
|---|---|---|
3a | Concepteur produit | Si détection d’une règle métier non respecté |
3a1 | Concepteur produit | Effectue une modification de la nouvelle pièce mécanique |
5a | Concepteur process | Si détection d’une infaisabilité process |
5a1 | Conception produit | Effectue une modification de la nouvelle pièce mécanique |
5 | Concepteur process | Vérifie la faisabilité process de la nouvelle pièce mécanique |
7a | Responsable produit/process | Si la revue d’acceptation de la nouvelle pièce est KO |
7a1 | Conception produit | Effectue une modification de la nouvelle pièce mécanique |
6) Identifier les peines du processus actuel
Une fois le processus métier décrit, il faut identifier les peines du processus actuel, c'est-à-dire, ce qui ne marche pas bien ainsi que les améliorations souhaitées.
En complément, il faudra déterminer les causes racines de ces peines notamment en utilisant la méthode des 5 pourquoi ?
Cette liste de peines est particulièrement importante :
- Elle recense l’ensemble des points durs qui doivent être résolus lors de la phase de recherche du logiciel PLM
- La résolution de ces points permettra de concrétiser les améliorations de performances opérationnelles attendues et donc de suivre l’avancement de l’atteinte de l’objectif de performance du projet
- Elle servira à faire adhérer les utilisateurs à la nouvelle solution PLM lors de la phase de déploiement en mettant en avant les gains d’utiliser la nouvelle solution par rapport à l’ancienne
Exemple de peines :
- Processus des échanges très compliqués entre les équipes Produit et Process : échange de fichier
- Beaucoup d'activités sans valeur ajoutée : manque d’automatisation
7) Compléter avec les exigences
Les exigences permettent de capter les compléments. Voici les différents types d'exigences :
- Fonctionnelle : Intégrer l’ensemble des règles métiers produit process de l’entreprise
- De performance : Améliorer d’au moins 50% le temps de traitement du scénario de référence
- D'ergonomie : Rester dans le même environnement pour : modifier la géométrie de la pièce, et créer et modifier toutes les contraintes process (outillages, support de montage, etc.)
Je vous recommande notre modèle de matrice des exigences, pour catégoriser du projet, les prioriser et suivre leur implémentation :
Modèle de la matrice des exigences
Avec une étude de cas concrète
8) Synthétiser le processus sous forme de diagramme
La dernière étape de la phase de formalisation des besoins métier est la synthèse du processus.
Une fois le document Word rempli et validé, on peut procéder comme suit :
- Créer un diagramme en utilisant différents outils de modélisation de graphe : en utilisant par exemple Gliffy, Draw.io, ou Lucidchart
- Positionner chaque acteur dans une ligne d’eau
- Au début du processus, on symbolise les livrables d’entrée
- Chaque activité du use case est symbolisée par une boite rectangulaire
- Chaque déclencheur est symbolisé par un losange et l’extension prend la forme d’une boucle de correction
- À la fin du processus, on symbolise les livrables d’entrée/sortie
- En complément, on peut identifier le processus père et le processus enfant
Comment gérer vos use cases ?
1) Établir une nomenclature
Pour pouvoir vous repérer entre vos différents use cases, vous pouvez les identifier par domaine fonctionnel en définissant une codification.
Par exemple, les use cases concernant la Gestion de Projet peuvent commencer par GP.
Le séquencement des use cases les uns par rapport aux autres peut se traduire par une numérotation chronologique : GP1, GP2, GP3 ...
S’il y a besoin de raffiner les sous processus, on peut utiliser plusieurs niveaux de numérotation : GP1_1, GP1_1_1, GP1_1_2, et ainsi de suite.
2) Utiliser des indicateurs
Pour pouvoir maitriser la convergence des use cases, on peut utiliser l'indicateur de maturité suivant :
- 20% Livrables d’entrée/sortie définis
- 40% Scenario nominal formalisé
- 60% Extensions définies
- 80% Exigences définies
- 100% Validé par Product owner et key users
3) Utiliser des outils de modélisation de processus
Une fois l’ensemble des use cases du périmètre formalisé, on peut utiliser des outils de modélisation de processus de type Aris ou Magic Draw, pour modéliser l’ensemble des interactions entre ces processus.
Ces outils permettent de vérifier la cohérence des processus entre eux au niveau :
- Du nom des acteurs
- Des livrables d’entrée/sortie (les livrables consommés par un processus doivent être produit par un autre processus de l’entreprise)
- Et de l’enchainement des processus entre eux de manière dynamique
On peut alors commencer :
- À rationaliser les livrables, par exemple : supprimer les doublons avec des noms de livrables différents par exemple, ou supprimer les livrables qui ne sont pas consommés
- À gérer au niveau de l'entreprise
- Et à optimiser les processus métier les uns par rapport aux autres
Conclusion
La phase de formalisation du besoin métier est fondamentale pour un projet PLM.
Elle permet d’aligner les utilisateurs sur les processus d'entreprise, qu’ils viennent d’entités différentes ou de localisations différentes.
Une fois que le besoin métier a été clairement identifié, aligné et dépoussiéré des différentes contraintes historiques dont il a fait l’objet, celui-ci est prêt pour la phase de convergence entre le besoin métier et le logiciel.
L’importance de la phase de formalisation du besoin est trop souvent sous-estimée ce qui conduit à :
- Soit à ne pas la faire : on préfère alors concevoir la Solution directement dans l’outil PLM sans partir du Besoin métier
- Soit à la faire de manière trop rapide ou imparfaite
Le risque, dans ce cas-là, est d’aboutir à une Solution PLM qui :
- Reflète les problèmes d’alignement des entités et les modes de fonctionnement en silos, entre entités
- Reproduit de manière dégradée les anciens processus métier
Dans ce cas, la frustration du Top management sera particulièrement importante :
- Le coût d’un tel projet est très significatif : licence PLM, intégrateur, matériel, charge interne métier et IT, perturbation opérationnelle
- La performance opérationnelle attendue n’est pas au rendez-vous
