Premier niveau d'analyse

Figure 6.1 Formalisation du processus d'appel d'ore en BPMN

6.2. Cas industriel de capitalisation Identier et formaliser

La première étape de notre méthodologie consiste à obtenir un consensus sur les processus métier. Il convient alors d'identier le ou les processus sur lesquels on se propose de travailler et de les formaliser (BPMN correspond au formalisme que nous avons retenu pour la formalisation des processus métiers).

Dans notre application industrielle, le processus en question correspond au processus de gestion des appels d'ore. Ce dernier a pour objectif de décrire les activités permettant de traiter la réception d'un appel d'ore jusqu'à la commande client.

Comme nous l'avons précisé dans le chapitre 2, de plus en plus d'entreprises sont aujourd'hui certiées ISO 9001. Cette norme fait partie des normes relatives au système qualité ; elle donne les exigences organisationnelles qui sont requises pour l'existence d'un système de management de la qualité. La société Marmillon, intervenant dans ces travaux en tant qu'exemple industriel fait elle-même l'objet d'une certication ISO 9001. Cette norme ISO 9001, n'impose pas de formalismes précis pour modéliser les processus métiers. Il convient donc dans cette étape soit de transcrire le processus en BPMN si ce dernier est déja existant, soit de le formaliser directement en BPMN pour les entreprises qui n'auraient aucun référentiel.

Le schéma (g. 6.1) représente les activités relatives au déroulement du processus d'appel d'ore. Les rôles ou experts qui interviendront pour valider les activités de ce processus métier ont été identiés.

Ce processus de gestion de l'appel d'ore fait appel à un sous processus en lien avec la réalisation du devis qu'il nous semble également intéressant de formaliser dans notre approche (g. 6.2). En eet, ce dernier fait appel à des éléments clefs du processus de développement d'un produit, en l'occurence dans notre exemple industriel, au développement d'une pièce plastique.

Figure 6.2 Formalisation du processus de réalisation du devis en BPMN

A partir du consensus obtenu autour du processus métier en question, il convient de l'analyser an d'en extraire les éléments clefs qui devront apparaitre dans le système PLM.

L'étude des activités du processus de gestion des appels d'ore et de son sous processus de réalisation du devis nous permet d'extraire les éléments clefs suivants :

appel d'ore devis commande pièce presse matière moule

Chapitre 6. Expérimentation et validation industrielles aaire

De plus, elle nous donne des indications sur les rôles nécessaire à son exécution : assistante commerciale,

directeur commercial, chargé d'aaires.

A l'issu de cette première étape, nous avons mis en évidence, les points clefs de ce processus.

Modéliser

Au cours de cette phase, il convient de dénir une première ébauche du modèle de données du système PLM. Dans le processus précédemment modélisé, plusieurs éléments clefs explicites ont été identiés : l'appel d'ore, le devis, la commande, ... Ces éléments peuvent être répartis en deux catégories de classes :

la première correspond à ce que l'on peut appeler des classes dites "documentaires" aux-quelles seront rattachés des chiers : appel d'ore, devis, commande.

la deuxième fait référence à des classes que l'on dénira comme des classes structurantes qui stockeront des données : aaire, moule, pièce, matière, presse. Ces classes constitueront l'ossature de notre aaire au sein du système.

Par la suite, il s'agit de dénir les relations et le type de lien. Pour notre application nous avons identié deux types de lien : "possède" et "est documenté par". Le lien "possède" sera utilisé entre les objets dits "structurants", alors que le lien "est documenté par" sera utilisé pour les objets dits "documentaires". Ainsi on aura des relations du type "une aaire possède une pièce",

"une pièce est documenté par un appel d'ore", etc.

Figure 6.3 Diagramme de classe du modèles de données

6.2. Cas industriel de capitalisation Enn, Il convient dans un troisième temps de construire les espaces d'états des classes pré-cédemment identiées. Cet espace d'état correspond aux enchainements des diérents états que va prendre l'objet durant son cycle de vie.

Figure 6.4 Exemple d'espace d'états de la classe Aaire

En fonction, des rôles dénis au préalable, des classes d'objet, ainsi que des espaces d'état, il convient de dénir le niveau de droit de chacun des rôles, pour chaque état de maturité de chacune des classes.

Cette étape a consisté à établir les diérents modèles du système. Classes d'objets, asso-ciations entre les classes, espace d'états, droits, processus, sont autant d'éléments identiés précédemment qui seront paramétrés dans le système via un module d'administration.

Utiliser/Instancier

Une fois modélisé, le système est testé aux moyens de jeux d'essai. Ces jeux d'essai servent à s'assurer que le système peux être utilisé en production. Ils permettent également de mettre en évidence des incohérences et les corriger. Le système est ensuite mis à disposition des utilisateurs.

Les classes sont instanciées, an de créer des objets. Les utilisateurs se servent du système pour stocker les données : poids de la pièce, matière utilisée, ect., mais également les documents : données CAO, appel d'ore, devis, Dossier d'Assurance Qualite Produit (DAQP), ect. Toutes les informations sont ainsi à disposition des employés de l'entreprise. Les objets de part leur statut et leur version orent la possibilité d'une traçabilité et confèrent à l'utilisateur la bonne information. Selon le prol de l'utilisateur et des droits dénis, chaque utilisateur a la vision sur les éléments le concernant.

D'un point de vue des processus, les modèles sont instanciés et un suivi des activités est réa-lisé. Chaque personne est ainsi à même de connaitre l'état d'avancement du projet en se référant aux processus instanciés. Lors de l'instanciation, les ressources sont aectées à chaque activité ainsi les utilisateurs sont informés des tâches leurs incombant via une notication automatique par e-mail.

Évaluer

Toutes activités dans le système sont recensées dans la base de données. Notre modèle d'éva-luation va s'appuyer et analyser le système ainsi que les traces générées. Comme nous le pro-posons au travers du chapitre 5, nous évaluons le modèle déni par notre approche. L'objectif est de réaliser un constat sur les modications apportées au modèle sur plusieurs point de vue : produit, processus, organisation.

Pour chacun de ces trois points, nous mesurons les modications réalisées sur les modèles.

Au travers d'une analyse des chiers de journalisation et d'informations contenus dans la base de données, nous analysons les éventuels ajouts, modication ou suppression qui ont pu être eectués au niveau des classes d'objets, des systèmes de droits, des statuts et des modèles de processus.

Chapitre 6. Expérimentation et validation industrielles

Cette analyse est à postériori et nous permet d'obtenir une appréciation sur l'application de notre méthodologie. Cette évaluation a pour but de valider notre approche, et le cas échéant de proposer des axes d'amélioration an de dénir un modèle de données le plus cohérent possible.