[PDF] FORMALISATION DES STRUCTURES ORGANISATIONNELLES





Previous PDF Next PDF



Formalisation de lentreprise

QuE SIgnIFIE LA FoRmALISATIon pouR. L'EnTREpRISE ? La formalisafion de l'entreprise désigne le processus dans lequel s'engagent les entreprises lorsqu'elles 



La formalisation des pratiques de gestion des ressources humaines

sociale sur la présence d'un ensemble de pratiques de GRH et sur le degré de formalisation de ces pratiques (par exemple la présence d'outils



De la nécessité dorganiser et coordonner le travail à la

Coordination – Organisation – Travail – Théorie - Formalisation démontrant que la structure d'une entreprise s'établit selon le degré de stabilité de.



Transition des entreprises informelles vers le formel : Les zones

La stratégie de mise en scène du choix du degré de formalisation des activités. Les entreprises sont informelles en ce sens que pour la plupart elles n'ont 



STRATEGIE NATIONALE INTEGREE DE FORMALISATION DE L

Les familles mécanique automobile et menuiserie bois ont à la fois un très faible degré de formalisation et un fort potentiel de développement.



FORMALISATION DES STRUCTURES ORGANISATIONNELLES

de l'espace des États est dépendante du degré de com- plexité souhaité. Une base minimale pour une entreprise qui souhaite garantir la traçabilité de ses 



Fascicule OPTIMISER LES PROCESSUS

1.2 Pourquoi les formaliser ? les optimiser ? Il faut enfin noter que le degré de formalisation d'un processus varie selon les compétences.



Formalisation des Entreprises : Une Introduction

tionnel déterminé le degré de formalisation d'une entreprise dépend de plusieurs facteurs comme par exemple la taille de l'entreprise





B - rubrique idees concepts n°19_B

courageant les entreprises informelles à se formaliser. « L'Actualité des services Degré de formalisation. Peu dynamique. Activité de subsistance.

3 e

Conférence Francophone de MOdélisation et SIMulation "Conception, Analyse et Gestion des Systèmes Industriels»

MOSIM'01 - du 25 au 27 avril 2001 - Troyes (France)

FORMALISATION DES STRUCTURES ORGANISATIONNELLES POURLE PARTAGE DES INFORMATIONS TECHNIQUES DANS LESENTREPRISES INDUSTRIELLES

Philippe PERNELLE

LLP/CESALP

Université de Savoie - ESIA

41, avenue de la plaine

BP 806

74000 Annecy, France

Mél : pernelle@univ-savoie.frAlain Courtois

LLP/CESALP

Université de Savoie - ESIA

41, avenue de la plaine

BP 806

74000 Annecy, France

Mél : courtois@univ-savoie.fr

RESUME :Le développement des produits s'inscrit depuis quelques années dans un cadre où les structures

industrielles sont distribuées. Les outils de type PDM (Product Data Management) ou SGDT (Système de Gestion de

Données Techniques) permettent de gérer les informations liées aux produits. Ces outils sont toutefois adaptés à ce

contexte distribué dans le cas d'entreprises distinctes. Notre but est de proposer un cadre de modélisation pour la

structuration des flux d'information et leur cycle de vie dans un processus de développement de produit où plusieurs

entités industrielles peuvent intervenir. Ce modèle s'appuie sur les capacités d'extension et de structuration fournies

par le langage XML. MOTS-CLES : PDM, SGDT, Système d'Information Produit, Ingénierie Simultanée, XML.

1. INTRODUCTION

L'entreprise s'adapte à son environnement, notamment en essayant de diminuer les délais et les coûts de dévelop- pement de ses nouveaux produits. Afin de mettre en oeuvre cette démarche, il est nécessaire de gérer les flux d'information liés aux produits pour tenter de capitaliser le savoir-faire de l'entreprise. Ainsi, les acteurs interve- nant dans le processus de développement pourront puiser dans cette mémoire d'entreprise afin de réutiliser les informations et les expériences antérieures. Actuelle- ment, il existe des outils qui essayent de répondre à cette ambition, les Product Data Management (Tollenaere et al, 1997) (Maurino, 1993) (Abramovici et Gerhard,

1997) (Pernelle et al, 2000). Leur implantation dans le

Système d'Information passe par la résolution de pro- blèmes divers : structuration, stockage, contrôle, évolu- tion et mise à disposition des données-produits. De nom- breux travaux existent afin de répondre aux problèmes de modélisation et d'échange des données techniques (CALS, EDI) et plusieurs démarches de normalisation sont en cours : PDM Schema (PDM-IF, 2000), PDM

Enablers (OMG, 2000), STEP (AFNOR, 1994). Ces

démarches visent à la constitution de modèle commun permettant l'échange de données entre différentes entre- prises. En effet, de nombreuses mutations apparaissent dans les structures industrielles. La vision intégrée de l'entreprise des années 80, laisse sa place à des structures plus petites, plus souples, plus réactives et organisées en réseau. On parle alors d'Entreprise Réseau (Jacob & al,

1996), (Poulin et al 1994) ou d'Entreprise Virtuelle

(Benabdelhafid et al, 1999). Implicitement, elles indui-sent des changements dans les méthodes de travail en

mettant en avant la nécessité de collaborer et de coopé- rer. Les problèmes de structuration de l'information se combinent alors avec les problèmes organisationnels. Nous proposons donc ici un modèle permettant d'intégrer l'éclatement des structures industrielles qui interviennent autour du développement d'un produit. Dans une première étape, nous proposons une modélisa- tion des flux d'information en tant que support de l'in- formation technique du produit. Cette représentation permet de définir simplement le produit et ses différents composants qu'ils soient organiques ou fonctionnels. La définition précise, à l'aide du langage XML, d'une partie de ce modèle est donnée à titre d'exemple. Dans une seconde étape, nous définissons une structure permettant la manipulation de ces différents flux à des fins de collaboration entre entreprises distinctes : Les Espaces Collaboratifs. L'objectif de ces Espaces Colla- boratifs est de donner les moyens à une structure indus- trielle de type PME/PMI " d'ouvrir » son Système d'Information à ses partenaires en vue de coopérer à un processus de développement de produit.

2. REPRESENTATION DU FLUX D'INFORMA-

TION DE PRODUIT

La modélisation du produit est destinée à représenter et à regrouper les données issues des différentes étapes de son cycle de vie. Elle est donc dépendante du métier de l'acteur qui la manipule et est composée d'éléments avec des natures et des complexités très diverses (modèle de MOSIM'01 - du 25 au 27 avril 2001 - Troyes (France) calcul, résultat de simulation, plan CAO, nomenclature de production, articles, etc.). Il convient d'ajouter que le modèle de produit doit être capable de traiter tous les niveaux d'abstraction du produit (Gzara et al, 1999) : conceptuel, générique et physique. Toutes ces données constituent les éléments du flux informationnel en entrée et en sortie des différentes activités du processus de développement des produits. Nous décrivons ce flux par un ensemble d'Entités Tech- niques (ET) qui peuvent se décomposer en trois types élémentaires : Les Objets Techniques, les Liens et les

États.

2.1. Flux des Entités Techniques

L'entité technique peut être vue comme une méta-classe de l'élément de base du flux d'information technique. Les Objets Techniques, les Liens, et les Etats constituent alors une spécialisation du flux d'information (Figure 1).

2.1.1 Description des sous-classes d'une Entité

Technique

Un Objet Technique (Ot) est un regroupement d'attributs définis sur un domaine de valeurs qui doit permettre de caractériser la structure statique d'un produit sur ses aspects constitutifs. Il peut être le support d'information concernant un article, un composant, ou un élément d'expérience. Un Lien (Ln) est une relation qui lie un Ot à un ou plu- sieurs Ot. Chaque lien porte un sens spécifique et pos- sède des propriétés qui lui sont propres (exemple : lien de nomenclature organique, lien de nomenclature fonc- tionnelle, lien documentaire, lien d'annotation, etc). Les États (Et) sont des entités permettant de caractériser l'évolution des éléments du flux au cours du temps. In- dépendamment de sa structure, chaque élément constitu- tif du produit (et sous-produit) possède un État qui peut être représenté sous la forme d'un vecteur. La dimension

de l'espace des États est dépendante du degré de com-plexité souhaité. Une base minimale pour une entreprise

qui souhaite garantir la traçabilité de ses données peut

être donnée par :

! la maturité, qui correspond à un état d'avancement d'un Ot (exemple : préliminaire , prototype, produc- tion, etc.), ! la révision, qui permet d'indicer les différentes ver- sions d'un Ot, ! le temps. La trajectoire d'un Ot est alors la séquence des Etats par lequel il est passé.

2.1.2 Représentation XML d'une Entité Technique

Les différentes sous-classes décrites précédemment doivent pouvoir être définies par tous les acteurs du Système d'Information Produit (SIP). Dans un contexte de collaboration elles doivent aussi permettre l'interopérabilité des SIP. Pour répondre à cette contrainte, nous avons choisi de les formaliser avec le langage XML (W3C, 2000). Ce langage de balises per- met de structurer un document à partir de la définition des éléments qui le composent. Ces éléments sont re- groupés au sein d'une DTD (Document Type Definition) qui permettra le cas échéant de vérifier la conformité d'un document XML avec sa définition. Afin d'illustrer nos propos, la figure 2 présente la défini- tion de la DTD d'un Objet Technique en tant que com- posant générique (OTCLASS) et en tant que composant physique (OT). Pour un objet technique les éléments de la DTD sont : ! la catégorie de l'objet (CLASSNAME), ! la référence de l'objet (ID), ! les attributs de l'objet technique (ATTRIBUTS,

ATTRIBUT, ATT),

! les domaines (DOMAIN) avec les contraintes sur ces domaines (CONSTRAINT), ! les valeurs associées à une contrainte (VALUE) ! les liens avec d'autres objets (LINK).

EvenementMessage

Operation_El

Att_Etat

Domaine

LienEtat

Attribut

1 0..* 1

0..*evolue dans

Vues

Objet Techniqueoperant

resultant

1..*1..*

possede

1..*1..*

0..*0..*

Flux_Entite_TechniqueFlux controle

Alarme

Jalon Figure 1. Formalisation UML d'une Entité Technique MOSIM'01 - du 25 au 27 avril 2001 - Troyes (France)

Figure 2. Extrait de la DTD d'un Objet Technique

L'exemple donné en figure 3 permet d'illustrer la cons- titution en XML d'une classe d'objet technique généri- que de type " ROTOR » à partir de la DTD définie pré- cédemment. ROTOR diametre interieur type 10 15 40 Figure 3. Exemple de définition d'un Objet Technique en XML2.2. Les vues Dans le cadre d'une coopération en ingénierie, l'équipe intervenante dans les tâches est composée d'acteurs di- vers dont la compétence et la vision du produit diffèrent les unes des autres. La notion de vue ou Point de vue (Harani, 1997) permet de répondre au problème en structurant l'information suivant des critères métier qui la rendent plus compréhensible. Dans une Vue (Figure 1), les attributs d'un Ot sont regroupés et éventuellement masqués.

2.3. Flux de contrôle

Les flux de contrôle vont permettre d'assurer la commu- nication, l'évolution et la pérennité des informations dans les étapes du processus. Ils se décomposent en plusieurs types d'éléments : ! les Événements décrivent une action effectuée sur une Entité Technique, ! les Messages permettent la communication entre les acteurs, ! les Alarmes sont des messages envoyés automati- quement par le système pour signaler un problème, ! les Jalons permettent de placer une balise sur des objets et de faire remonter ces informations dans une gestion de projet. L'ensemble des classes décrites sur le schéma UML de la figure 1 est formalisé dans une DTD. Ainsi tous les flux (d'entités techniques ou de contrôle) peuvent être interprétés par un Système d'Information externe à l'entreprise.

3. PARTAGE ET ECHANGE D'INFORMATION

DANS LES ESPACES COLLABORATIFS (EC)

Si la nécessité de collaborer apparaît de façon évidente, elle implique inévitablement un partage de l'information. L'importance de la structure organisationnelle va être un des éléments majeurs de la configuration du Système d'Information Produit. Le but des Espaces Collaboratifs (Figure 4) est de repré- senter ces structures organisationnelles et information- nelles qui vont permettre un travail collaboratif dans le cadre d'entreprises distinctes. Nous présentons les diffé- rents éléments permettant leur mise en oeuvre : ! les unités organisationnelles, ! les bus de données et de contrôle, ! les activités et les initiatives, ! les connecteurs. MOSIM'01 - du 25 au 27 avril 2001 - Troyes (France) Figure 4. Les Espaces Collaboratifs dans le processus de développement des produits

3.1. Les organisations distribuées

Dans notre cas d'étude, l'entreprise se décompose en plusieurs sous-systèmes - les Unités Organisationelles (UO) - disposant d'une certaine autonomie d'actions avec des objectifs spécifiques. Une UO (Figure 4) regroupe différents éléments assez hétérogènes puisque l'on y retrouve des acteurs de l'entreprise, des équipes, des services et des rôles. • Le service est utilisé pour représenter la décomposi- tion structurelle de l'entreprise, • L'équipe définit un regroupement d'acteurs liés à un projet, • La notion de rôle est utilisée pour caractériser les capacités d'action sur les flux d'information. Le rôle est finalement un ensemble de droits et de fonctions.3.2. Bus de données / contrôle Les bus sont des middlewares devant assurer la persis- tance des données générées et leur mise à disposition aux différents composants logiciels du SIP. Ils correspondent en fait au fonctionnement de base d'un PDM.

3.3. Activités / Aptitudes

La mise en oeuvre d'une démarche d'ingénierie simulta- née (Jagou, 1993) implique l'utilisation d'outils de coor- dination du travail coopératif. Ils sont basés sur des mo- dèles qui distinguent deux approches : • l'approche conversationnelle (Winograd, 1988) (Conklin, 1988), • l'approche orientée activité qui prend en compte les acteurs coopérant dans la structure organisationnelle de l'entreprise (Smith et al, 1991) (dillmore et al,

1991) (Tichkiewitch S. et al, 1998).

Une approche orienté activité implique une maîtrise et un suivi des différents processus qui aboutissent à la réalisation d'un produit. En phase de conception, le pro- cessus est souvent peu structuré, c'est-à-dire qu'il est difficile de prédire l'enchaînement des activités qui le composent. En phase de production, le processus est structuré mais relativement complexe. Dans le cadre des EC, l'activité (Figure 6) est l'élément constituant de base et peut-être défini par : • des pré-conditions et des post-conditions qui vont permettre le déclenchement de début et de fin de la tâche, • un ensemble d'états conditionnels, c'est-à-dire tel que le passage d'un état à un autre soit soumis à condition, • un ensemble d'objectifs correspondant aux attentes en sortie de flux,

Action

ServiceEquipe

Acteur

1..*1..*

1..*1..*

Acteur_Externe

VueDroit

1..*1..*

Role

1..*1..*

FonctionFlux_Controle

1..*1..*

Organisation

1..*1..*

Objectif

Connecteur

Unite

1..*1..*

0..*0..*

Figure 5. Formalisation UML de la structure organisationnelle d'un EC MOSIM'01 - du 25 au 27 avril 2001 - Troyes (France) • un ensemble d'indicateurs qui vont permettre de mesurer le déroulement de l'activité suivant des critères pré-établis • un ensemble d'acteurs qui correspondent aux élé- ments constitutifs des Unités Organisationnelles, • des Flux d'entrée et de sortie constituées d'Entités

Techniques et de Flux de Contrôle),

• des composants logiciels qui permettent l'exécutionquotesdbs_dbs50.pdfusesText_50
[PDF] degré de liberté mécanique exercice

[PDF] degré dornic d'un lait

[PDF] degré dornic d'un yaourt

[PDF] dégrèvement

[PDF] dégustation de vin pdf

[PDF] deja de ser tu audiolibro

[PDF] deja de ser tu joe dispenza resumen

[PDF] deja de ser tu meditacion

[PDF] deja de ser tu precio

[PDF] deja de ser tu reseña

[PDF] deja de ser tu sinopsis

[PDF] delabie

[PDF] délai déblocage des fonds prêt consommation

[PDF] délai déclaration impôts vaud

[PDF] delai entre decret naturalisation ceremonie