PLM : formaliser un besoin métier à l’aide d’un use case

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.

kit du chef de projet 0923
outils du chef de projet 0923

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 :

domaines du PLM

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. 

template de use case

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 :

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 :

extensions 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

matrice des exigences plm

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
le kit du chef de projet 0923
outils du chef de projet 0923

Comment gérer vos use cases ?

plm use case

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

Jean Noel Bos

A propos de l'auteur

Jean-Noël est un directeur de projet senior qui dispose d’une double compétence IT et R&D.
Il a piloté plusieurs projets informatiques R&D à forts enjeux de transformation, notamment des projets PLM, mais aussi plusieurs projets véhicules au sein de la R&D d'un grand groupe automobile.
Il souhaite partager sa connaissance des projets PLM avec les lecteurs du blog afin de vulgariser le PLM et de les guider dans la mise en œuvre de ces projets complexes.

Les autres articles du dossier 

{"email":"Adresse email invalide","url":"Url du site invalide","required":"Champ obligatoire non renseigné"}

Guide GRATUIT du chef de projet

25 points clés que la plupart des chefs de projet négligent dans la gestion de leurs projets (+ concepts et notions clés).

>