Modèle des données : comment faire la modélisation des données d’une solution PLM, avec exemple

Dans un projet PLM, le modèle des données est un prérequis incontournable aux travaux de convergence entre le besoin métier et la solution PLM.

Cet article a pour objectif de vous faire comprendre ce qu'est un modèle des données (MDD) dans le contexte d’un projet PLM, ainsi que son importance dans la mise en œuvre d’une solution performante.

L’article n'a pas vocation à être exhaustive.

Je souhaite simplement illustrer, à travers un acte quotidien, la notion de modélisation des données et de son impact.

modèle des données projet plm

Qu’est-ce qu’un modèle des données ?

Un prologiciel PLM est une surcouche d’une Base Données (par exemple : Oracle).

Le Modèle des données PLM défini la structure logique des données entre elles ainsi que leur type de relation.

Exemple pour comprendre le modèle des données

Prenons un exemple pour illustrer la modélisation des données dans un projet PLM.

Dans cette illustration, les données sont représentées par des vêtements.

Mon objectif est d’améliorer la performance opérationnelle du Use Case suivant :

M'habiller pour prendre mon bus.

use case modèle de données plm

Problématique

Initialement, pour m'habiller, je choisis les vêtements que je vais porter dans l’ensemble parmi les vêtements de la famille rangés en vrac.

La peine que j’identifie dans mon processus actuel est que :
"Je loupe le bus, car je perds du temps à m’habiller"

Je ne veux plus rater mon bus pour aller travailler donc je dois optimiser ma solution.

modèle de données itération 1

P : problème / S : solution

Solution

Pour ce faire, j’engage une démarche d’amélioration continue dont voici les étapes :

1) 1ʳᵉ itération d’amélioration continue

Je commence par identifier une première cause à mon problème :

"J’ai trop de vêtements".

J’engage donc une première action pour me séparer des vêtements que je ne porte plus.

Je mesure le résultat de la nouvelle solution et je constate que la situation s’est améliorée, mais que je loupe encore mon bus.

2) 2ᵉ itération d’amélioration continue

Je poursuis donc ma démarche d’amélioration continue et j’identifie une seconde cause à mon problème :

"Je n’ai pas de système de rangement".

modèle de données itération 2

J’engage donc une seconde action pour m’équiper d’une armoire qui me permet de
séparer mes vêtements de ceux de mon/ma conjoint(e).

Je mesure le résultat de la nouvelle solution et je constate que la situation s’est améliorée, mais que je loupe encore mon bus.

Je poursuis donc ma démarche d’amélioration continue et j’identifie une troisième cause à mon problème :

"Je perds du temps à trouver chaque élément de ma tenue, car ils sont mélangés dans mon armoire : chapeau, haut, bas, sac, chaussures".

modèle de données itération 3

3) 3ᵉ itération d’amélioration continue

J’engage donc une troisième action en installant 4 étagères dans mon armoire qui me permette de ranger tous les vêtements d’un même type :  chapeau, haut, bas, sac, chaussures.

Je mesure le résultat de la nouvelle solution et je constate que la situation s’est améliorée, mais que je loupe encore mon bus.

3) Dernière itération d’amélioration continue

Je poursuis donc ma démarche d’amélioration continue et j’identifie une dernière cause à mon problème :

"Je perds du temps à choisir entre les différents vêtements d’un même type".

modèle de données itération 4

J’engage donc une quatrième action en rangeant mes vêtements avant le début de semaine
suivant le jour où je dois les porter : lundi, mardi, mercredi, jeudi, vendredi

Je mesure le résultat de la nouvelle solution et je constate que je ne rate plus bon bus !

À noter, que si mon objectif avait été d’optimiser la performance du Use Case suivant :

"Laver mes vêtements".

Et si la peine avait été :

"Je perds une journée à trier mes vêtements avant de pouvoir faire une machine à laver".

La solution aurait été différente.

On aurait pris par exemple le choix de ranger les vêtements par couleur pour supprimer l’activité de tri avant de faire une machine à laver.

Synthèse

Que peut-on tirer comme conclusion de cette illustration de construction d'un modèle des données ?

La manière d’organiser les vêtements impacte la performance des processus (Use Case) que l’on souhaite optimiser.

De même, la façon dont on organise les données dans un PLM impacte directement la performance des Use Case donc des processus métier à outiller.

Comment construire un modèle des données PLM ?

Cette manière d’organiser les données que nous venons de voir correspond au modèle des données du PLM.

Comment procède-t-on ?

Voyons ci-après les étapes :

1) Récupérer les données des use case

À la fin de la phase de formalisation des Use Case, on dispose de l’ensemble des données à gérer au niveau du PLM de l’entreprise.

On peut alors construire un modèle des données fonctionnel dans des outils comme Aris ou Magic Draw en relation avec la modélisation des processus.  

Cette démarche va permettre de rationaliser les données à gérer. Il faut vérifier que :

  • Chaque donnée est unique
  • Chaque donnée est bien produite et consommée
  • Chaque donnée interne à un processus n’est pas gérée au niveau "entreprise"

2) Réaliser un mapping des processus métier

À partir de ce modèle des données fonctionnel, la solution architecte chargée de la définition de solution PLM, va réaliser un mapping avec les différents objets et types de relations disponibles dans le progiciel choisi pour implémenter la solution PLM.

Ce mapping devra tenir en compte des processus métier que l’on souhaite privilégier en termes de performance, comme nous l’avons vu dans notre illustration.

3) Engager les travaux MDD au bon moment

Avant le démarrage des travaux de convergence entre le besoin métier et la solution PLM, il est fortement recommandé qu’un certain nombre de fondamentaux du modèle des données (MDD) soient figés.

En effet, si la phase de convergence est réalisée par plusieurs équipes travaillant par Stream en parallèle, ces fondamentaux de modélisation des données permettront de garantir la cohérence d’ensemble du projet PLM.

Si ce travail n’est pas réalisé, chaque équipe définira son propre MDD, et il est hautement probable que ceux-ci soient incompatibles entre eux, et entrainent, pendant la phase d’intégration des travaux de chaque Stream, des remises en cause profondes et tardives.

Les sujets principaux pouvant faire partie de la liste des fondamentaux MDD sont :

  • Structure Produit
  • Gestion de la diversité et configuration produit
  • Référencement pièces et versionement
  • Catalogues et référentiels de pièces
  • Gestion des connecteurs d'interface entre pièces
  • Nomenclature d'assemblage
  • Vues métiers
  • Gestion de projet (livrables attendus à chaque jalon)

Conclusion

La construction du modèle des données dans un projet PLM est fondamentale.

Elle permet :

  • De garantir la performance et l’efficacité de la solution PLM
  • De garantir la cohérence d’ensemble du projet PLM

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).

>