RAPPORT DE PROJET DE FIN D’ÉTUDES

Présenté en vue de l’obtention du Diplôme National d’Ingénieur

Spécialité : Informatique

Option : Ingénierie Informatique

Par

Rawdha MABROUKI

Entreprise d’accueil

Encadrant académique

Madame Yemna SAYEB

Encadrant académique

Madame Yemna SAYEB

Encadrant professionnel

Monsieur Aladine AZIZ

Année universitaire

2015/2016

Année universitaire 2015/2016

Conception et Développement d’un Module

GMAO autour de l’ERP Microsoft Dynamics Ax

Rawdha Mabrouki

RAPPORT DE PROJET DE FIN D’ÉTUDES

Présenté en vue de l’obtention du Diplôme National d’Ingénieur

Spécialité : Informatique

Option : Ingénierie Informatique

Par

Rawdha MABROUKI

Entreprise d’accueil

Encadrant professionnel

Monsieur Aladine AZIZ

Encadrant professionnel

Monsieur Aladine AZIZ

Encadrant académique

Madame Yemna SAYEB

Encadrant académique

Madame Yemna SAYEB

Conception et Développement d’un Module

GMAO autour de l’ERP Microsoft Dynamics Ax

Année universitaire

2015/2016

Année universitaire 2015/2016

Rawdha Mabrouki

Rawdha Mabrouki

Encadrant Cynapsys

Encadrant SESAME

Signature

Cachet

Signature

Rawdha Mabrouki

Dédicaces Avec tout respect et amour je dédie ce modeste travail

À mes chers parents Mohsen et Najiba, aucune dédicace ne saurait être

assez éloquente pour exprimer ce que vous méritez pour tous les sacrifices

que vous n’avez pas cessé de me donner depuis ma naissance. Je vous dédie

ce travail en témoignage de mon profond amour.

À mes grands-parents Lamine et Charifa, puisse Dieu le tout

puissant vous préserver et vous accorder santé, longue vie et bonheur.

À mon cher frère Jihad et mon adorable frère Kais.

À tous mes amis en souvenir des plus beaux instants qu’on a passés

ensemble.

Aussi bien à tous ceux qui m’ont aidé et encouragé pendant mon

cursus universitaire à SESAME ainsi que à l’ISI.

Rawdha

Rawdha Mabrouki

Remerciements

Ce rapport de projet de fin d’étude d’ingénieur en informatique est le fruit d’un travail mené au

sein de l’ESN Cynapsys. Je remercie tous ceux qui m’ont accueilli bras ouverts au sein de la

société. Je voudrais exprimer toute ma gratitude pour leur confiance et les moyens techniques

et scientifique qu’ils ont mis à ma disposition et sans qui ce travail n’aurait jamais été

envisageable.

Au terme de ce stage, je tiens tout particulièrement à remercier monsieur Aleddine AZIZ

consultant technico-fonctionnel Microsoft Dynamics AX et chef d’équipe .Net à Cynapsys,

pour avoir choisir le thème du sujet puis pour l’encadrement du travail. Sa disponibilité, ses

conseils éclairés, ses réponses aux différentes questions et son soutien m’ont été d’une aide

inestimable et ont largement contribué à ma formation.

Je tiens tout spécialement à exprimer ma sincère gratitude et estime envers mon encadrante à

SESAME madame Yemna SAYEB BELHASSEN maître assistante et conseillère MESRST.

Pour l’aide compétente qu’elle m’a apportée, pour sa patience, sa disponibilité et son

encouragement. Ses critiques ont été très précieuses pour structurer ce travail et pour améliorer

la qualité des différentes sections.

Tout au long de ce travail, et plus généralement de mon parcours réalisé ces dernières années,

j’ai pu bénéficier de soutiens, de conseils et d’encouragements d’un très grand nombre de

personnes auxquelles je tiens à exprimer toute ma gratitude.

Rawdha MABROUKI

Sommaire

INTRODUCTION GENERALE 1

CHAPITRE I. CONTEXTE DE PROJET 1

I.1. INTRODUCTION 1

I.2. PRESENTATION DE L’ORGANISME D’ACCUEIL 1

Cynapsys IT Hotspot en bref 1

Directions de Cynapsys Tunis 2

Produits de Cynapsys Software Engineering 2

Organigramme d’une ESN 3

I.3. APERÇU DU PROJET 3

Thème du sujet 3

Travail demandé 4

I.4. METHODOLOGIE ET FORMALISME ADOPTES 4

Méthodes agiles 4

Méthode de conception 6

Formalisme adopté 7

I.5. CONDUITE DE PROJET 7

I.6. CONCLUSION 8

CHAPITRE II. ÉTAT DE L’ART 9

II.1. INTRODUCTION 9

II.2. ENTREPRISE INDUSTRIELLE 9

Modèle organisationnel 9

Mesure de performance de l’entreprise 10

II.3. ANALYSE DU METIER MAINTENANCE 11

Équipements industriels 11

Fonction maintenance industrielle 11

Rôles et responsabilités 12

Formes de maintenance 12

Gestion de maintenance 14

Processus de maintenance 15

II.4. SYSTEMES D’INFORMATION DE GESTION D’ENTREPRISE 16

Inconvénients des SI traditionnels 17

Rawdha Mabrouki

Entreprise Ressource Planning 17

Étude fonctionnelle de Dynamics Ax 21

II.5. GESTION DE MAINTENANCE ASSISTEE PAR ORDINATEUR 21

Rôles du GMAO 22

Fonctionnalités de base 22

II.6. ÉTUDE DE L’EXISTANT 23

Intégration d’une solution GMAO 23

Paramétrage d’une solution GMAO sur Dynamics Ax 24

Tableau de synthèse 25

II.7. PROBLEMATIQUE 26

II.8. CONCLUSION 26

CHAPITRE III. ÉTUDE PREALABLE 27

III.1. INTRODUCTION 27

III.2. SOLUTION PROPOSEE 27

Démarche adoptée 27

Cartographie des processus 28

Communication avec autres processus 29

III.3. BACKLOG PRODUIT 29

Spécification des exigences 29

Identification des acteurs 29

Besoins fonctionnels 30

Besoins non fonctionnels 33

Planification des itérations 33

III.4. ENVIRONNEMENT TECHNIQUE ET LOGICIEL 33

Architecture logicielle de Dynamics Ax 34

Couche accès aux données 34

Couche présentation 35

Couche métier 37

Environnement de développement intégré 37

Workflow de Dynamics Ax 38

Principes de conception architecturale du Dynamics Ax 38

III.5. CONCLUSION 39

CHAPITRE IV. ÉLABORATION DU SPRINT 1 40

Rawdha Mabrouki

IV.1. INTRODUCTION 40

IV.2. SPRINT BACKLOG 40

Étude du module immobilisation 40

Cas d’utilisation gestion des équipements 41

IV.3. CONCEPTION GENERALE 41

Raffinement du cas d’utilisation Ajouter équipement 41

Raffinement du cas d’utilisation ‘Consulter détail équipement’ 44

Raffinement de cas d’utilisation Élaborer demande de Travail 44

Diagramme d’état transition de l’objet métier équipement 45

IV.4. CONCEPTION DETAILLEE 46

Diagramme de classe 46

Schéma relationnel de la base de données 47

IV.5. REALISATION 48

IV.6. CONCLUSION 53

CHAPITRE V. ÉLABORATION DU SPRINT2 ET 3 54

V.1. INTRODUCTION 54

V.2. SPRINT BACKLOG 54

V.3. CONCEPTION GENERALE 54

Diagrammes activité 54

Raffinement du cas d’utilisation gérer ordres de travail’ 57

Raffinement du cas d’utilisation gérer demandes travail 58

V.4. CONCEPTION DETAILLE 58

Raffinement du cas d’utilisation consulter ordre de travail 58

Raffinement du cas d’utilisation ajouter ordre de travail 59

Raffinement du cas d’utilisation consulter demande 62

Raffinement de cas d’utilisation demander Travail 62

Raffinement de cas d’utilisation gérer les interventions 64

Raffinement de cas d’utilisation affecter techniciens 64

Raffinement de cas d’utilisation gérer les contrats 65

Diagramme de classes 67

Flux de travail de l’ordre de travail 70

V.5. DESIGN DE L’EXPERIENCE UTILISATEUR 70

V.6. REALISATION 72

Rawdha Mabrouki

Interfaces de gestion de demande de travail 73

Interfaces de gestion des ordres de travail 76

Interfaces d’ordonnancement d’intervention 78

Interfaces d’affectation techniciens 79

Interfaces de gestion des contrats de maintenance 80

Impression des documents de maintenance 81

V.7. CONCLUSION 81

CONCLUSION GENERALE 82

BIBLIOGRAPHIES I

WEBOGRAPHIE IV

GLOSSAIRE V

ANNEXES VII

ANNEXE A VII

ANNEXE B VIII

ANNEXE C XI

Rawdha Mabrouki

Liste des figures

Figure I-1 : Pôles de Cynapsys [W1] 2

Figure I-2 : Direction technique d’une ESN [W2] 3

Figure I-3 : Comparaison entre Cascade et Scrum [W3] 5

Figure I-4 : Processus Scrum [W3] 6

Figure I-5 : Diagrammes UML (Nathalie, 2000) 7

Figure I-6: Diagramme de Gantt prévisionnel 8

Figure II-1 : Exemple d’hiérarchie organisationnel (Shelly, 2012) 10

Figure II-2 : Relation entre KPI, KRI,RI et PI 10

Figure II-3 : Part de la maintenance dans le CA (Marc St-Marseille, 1997) 12

Figure II-4 : Formes de maintenance (AFNOR, 2016) 13

Figure II-5 : Charte de Sélection des ERP propriétaires 19

Figure II-6 : Diagramme cause/effet problèmes de papiers (Marc St-Marseille, 1997) 22

Figure II-7 : Fonctions du GMAO (R.Keith Mobley) 22

Figure II-8 : Tableau de bord d’Oracle eAM (solution, 2015) 24

Figure II-9 : Interface List page de Dynaway [W8] 25

Figure III-1 : Feuille de route de développement de module MDX 27

Figure III-2 : Cartographie des processus 28

Figure III-3 : Diagramme de contexte statique 30

Figure III-4 : Diagramme de cas d'utilisation générale 32

Figure III-5 : Architecture trois tiers de Dynamics Ax (Team, 2012) 34

Figure III-6 : Rôle Center (Keith Dunkinson, 2013) 36

Figure III-7 : Page de Secteur 37

Figure IV-1 : Aperçu du module immobilisation [W9] 40

Figure IV-2 : Diagramme de cas d’utilisation ‘Gérer les équipements 41

Figure IV-3 : Diagramme de séquence de scénario nominale d’Ajout équipement 43

Figure IV-4 : Diagramme de cas d’utilisation consulter détail 44

Figure IV-5 : Diagramme de séquence élaborer demande Travail 45

Figure IV-6 : Diagramme d’état transition de l’objet équipement 46

Figure IV-7 : Diagramme de classes de Sprint 1 47

Figure IV-8 : Schéma relationnel de la base de données de Sprint 1 48

Figure IV-9 : Formulaire d’ajout d’un compteur 49

Figure IV-10 : Interface d’ajout d’un équipement 49

Rawdha Mabrouki

Figure IV-11 : Formulaire de gestion d’une pièce 50

Figure IV-12 : Interface de gestion d'outil de maintenance 50

Figure IV-13 : Interface List Page des équipements 51

Figure IV-14 : Interface de gestion des accessoires 51

Figure IV-15 : Interface de planification d'un préventif 52

Figure IV-16 : Interface Master Détails d’un équipement et DropDialog demander travail 52

Figure IV-17 : Interface de consultation de l'historique des pannes 53

Figure V-1 : Diagramme état-transition de l’objet OT 55

Figure V-2 : Diagramme état-transition de l’objet DT 55

Figure V-3 : Diagramme activité gestion des ordres de travail 56

Figure V-4 : Diagramme d'activité demander travail 57

Figure V-5 : Diagramme de cas d’utilisation gérer les ordres de travail 57

Figure V-6 : Diagramme de cas d’utilisation gérer les demandes de travail 58

Figure V-7 : Diagramme de cas d’utilisation consulter ordre de travail 59

Figure V-8 : Diagramme de séquence nominale d'ajout d'un OT 60

Figure V-9: Diagramme séquence de génération d'un OT suite à une Demande 61

Figure V-10 : Diagramme de cas d’utilisation consulter demande travail 62

Figure V-11 : Diagramme de séquence demander travail 62

Figure V-12 : Diagramme de cas d'utilisation gérer les interventions 64

Figure V-13 : Diagramme de cas d'utilisation affecter techniciens 64

Figure V-14 : Diagramme de cas d'utilisation gestion des contrats de maintenance 65

Figure V-15 : Diagramme de séquence d'ajout d'un contrat de maintenance 66

Figure V-16 : Diagramme de classes 68

Figure V-17 : Schéma relationnel de la base de données 69

Figure V-18 : Flux de travail du processus de gestion d'ordre de travail 70

Figure V-19 : Prototype de l'interface d'ordonnancement des interventions 71

Figure V-20 : Aperçu du prototype : la page de zone 71

Figure V-21 : Héritage de la table mère GmaoOrdreTravail 72

Figure V-22 : Interface ListPage de demande de travail 73

Figure V-23 : Interface DropDialog de mise à jour de statu demande 74

Figure V-24 : Interface de choix d'un ordre de travail 75

Figure V-25 : Interface Master Détails modification des demandes dans la grille 75

Figure V-26 : Interface de génération d'un OT à partir d'un DT 76

Figure V-27 : Interface List page de gestion des ordres de travail 76

Rawdha Mabrouki

Figure V-28 : Interface de consultation d’ordres de travail 77

Figure V-29 : Interface de modification d'un ordre de travail 77

Figure V-30 : Interface d'ordonnancement d'intervention vue ligne 78

Figure V-31 : Interface d’ordonnancement d’intervention 78

Figure V-32 : Interface de gestion d'intervention 79

Figure V-33 : Interface d’affectation de technicien 79

Figure V-34 : Interface de gestion des contrats de maintenance 80

Figure V-35 : Interface d'ajout d'un contrat de maintenance 80

Figure V-36 : Impression de l'ordre de travail 81

Figure V-37 : Impression des interventions 81

Rawdha Mabrouki

Liste des tableaux

Tableau II-1 : Tableau comparatif entre SAP et Ax [W6], (Blokdijk, 2015) 20

Tableau II-2 : Récapitulatif des solutions GMAO étudiées 26

Tableau III-1 : Aperçue de la planification des itérations 33

Tableau III-2 : Modèle de couches de Dynamics Ax (Birch, 2013) 39

Rawdha Mabrouki

Liste des abréviations

ESN

ERP, PGI

GMAO

CMMS

EAM

CMMI

PME PMI

J2EE

CLT

ASD

FDD

CASE

UML

OMG

BPMN

CEO

RI

PI

KRI

KPI

SI

MDX Axapta

SAP

IBM

SQL

ABAP

IHM

SCM

CRM

PM

AMDEC

TPM

LLC

DT

OT, WO

BI

KPI

CRUD

SGBD

SSRS

SSIS

SSAS

OLTP

OLAP

ETL

AOS

AOT

MDLA

Entreprise du Services de Numérique

Enterprise Ressource Planning, Progiciel de Gestion Intégrée

Gestion de Maintenance Assisté par Ordinateur

Computerized Maintenance Management System

Enterprise Asset Management

Capability Maturity Model + Integration

Petites et Moyennes Entreprises, Petite et Moyennes Industries

JAVA 2 Enterprise Edition

Carbon & LCA Tools

Adaptive Software Development

Feature Driven Development

Computer Aided Software Environment

Unified Modeling Language

Object Management Group

Business Process Modeling Notation

Chef Exécutif Officié

Result Indicator

Performance Indicator

Key Result Indicator

Key Performance Indicator

Système d’Information

Microsoft Dynamics Ax

Systems, Applications et Products for data processing

International Business Machines

Sequence Query Language

Advanced Business Application Programming

Interface Homme Machine

Supply Chain management

Customer Relation Management

Preventive Maintenance

Analyse des Modes de Défaillance, de leurs Effets et de leur Criticité

Total Productive Maintenance

Life Cycle Cost

Demande de Travail

Ordre de Travail, Work Order

Business Intelligence

Key Performance Indicator

Create, Retrieve, Update, and Delete

Système de Gestion de la Base de Données

SQL Server Reporting service

SQL Server Integration Service

SQL Server Analysis Service

On Line Transactional Processing

On Line Analytical Processing

Extract, Transform, Load

Application Object Server

Application Object Tree

Model-Driven Layered Architecture,

Rawdha Mabrouki

1

Introduction générale

L’entreprise industrielle est un système évolutif qui a besoin d’une politique innovatrice. En

termes d’innovation, l’implantation d’un système d’information qui permettra d‘optimiser ces

fonctions devient un besoin urgent.

La maintenance industrielle est l’une des fonctions de l’entreprise innovante. Elle n’a plus

aujourd’hui comme seul objectif de réparer l’outil de production mais aussi d’en prévoir et

d’éviter les dysfonctionnements et en améliorer les performances. En fait le rôle de gestionnaire

de maintenance est de gérer les ordres de travail, à la nécessité de réduire les coûts de production

et d’optimiser l’utilisation des machines, et au respect des normes d’hygiène, de sécurité et

d’environnement. D’ailleurs pour les entreprises dont les coûts de maintenance sont élevés et

dont les effectifs à gérer son en croissant, causant une augmentation de l’information à traiter,

mettent en place de nouvelle politique de maintenance.

L’émergence de nouvelles politiques de maintenance sont les préludes à une nouvelle période

pour l’informatisation de la maintenance, celle que certains appellent GMAO : la gestion de

maintenance assistée par ordinateur. Cette dernière occupe une part importante et exige une

modélisation rigoureuse permettant par la suite son automatisation.

D’une autre part, ces systèmes sont utiles pour évaluer l’état de la maintenance dans les

différentes unités des usines de production. Ils donnent aux dirigeants une visibilité sur la

performance de service de maintenance afin d’améliorer la capacité de celle-ci et à réagir plus

rapidement aux problèmes liés à la maintenance.

Une entreprise industrielle qui utilise un progiciel de gestion intégré, tel Microsoft Dynamics

Ax, en tant que système d’information, vise à mettre en place une GMAO autour des modules

existant en prenant en compte l’intégration et l’hétérogénéité des interfaces utilisateurs.

En effet les solutions du GMAO du marché sont proposées soit par des sociétés spécialisées

dans les ERP ou des sociétés spécialisées dans la gestion de maintenance. La deuxième solution

vaut des coûts supplémentaires d’intégration et de maintenance. La première solution est

coûteuse en termes d’adaptation aux besoins spécifique de l’entreprise, ainsi que la plupart des

solutions sont compliqué et ce qui ajoute le coût de formation des utilisateurs. En conséquence,

Rawdha Mabrouki

2

la conception et le développement d’un nouveau module GMAO autour de l’ERP Dynamics

Ax est la solution la plus adéquate. Alors l’une des principales questions à laquelle s’intéresse

ce rapport est comment modéliser et développer un progiciel de GMAO, efficace et garantie la

vision de l’entreprise, ainsi qu’un outil de planification, de contrôle de coût et d’aide à la

décision adéquat à l’entreprise industrielle.

Dans ce contexte nous avons réalisé un stage de période de six mois, a pour but de concevoir

puis développer une solution GMAO de l’ERP Microsoft Dynamics Ax. Alors Après 5 ans

d’étude, suivre un stage dans une entreprise devient une nécessité dont l’objectif est d’appliquer

les connaissances pratiques et théoriques afin de se familiariser avec la réalité professionnelle

et s’adapter au monde du travail. La société Cynapsys, où nous avons effectué notre stage est

une ESN qui transforme les compétences et expertises de ses associés en solutions

informatiques. Nous avons eu l’occasion d’effectuer notre stage d’étude au sein du pôle .Net de

Cynapsys avec l’équipe Microsoft Dynamics Ax. Le travail consiste à effectuer d’abord une

analyse du besoin du GMAO afin de bien souligner les différentes fonctionnalités requises.

Ensuite à chercher parmi ces fonctionnalités celles qui sont déjà offertes par Dynamics Ax, afin

d’éviter la redondance, qui peut résulter des coûts de développement supplémentaires et des

complexités lors de la mise à niveau vers les futures release de Dynamics Ax. Puis nous allons

découper les fonctionnalités en des sous-modules. Alors pour garantir la livraison de chaque

fonctionnalité, il faut concevoir, pour concevoir il faut formaliser. Donc pour chaque sous-

module nous allons réaliser la conception et le développement. La conduite d’un projet d’ERP

est différente de celle d’un projet de développement. Or il faudra une première étape qui permet

de réaliser une étude par rapport l’organisation de l’entreprise et ses modes de fonctionnement

qui doivent être respectés. Puis il faut analyser le système existant. Afin de gérer notre projet

nous avons choisi la méthodologie Scrum. Donc le cycle de vie de projet démarre avec un

premier Sprint pour réaliser la conception et la personnalisation du module de gestion des

équipements. Ensuite, le Sprint 2 est consacré à la réalisation du module de gestion des ordres

de travail. Le Sprint 3 est planifié pour le développement du sous-module de gestion des

contrats d’externalisation et planification de la maintenance. Enfin le dernier Sprint dernier sera

programmé à développer les clés de performance et le reporting.

Je m’attache dans ce rapport à présenter l’ensemble de l’étude, et notamment la démarche

scientifique qui m’a amené jusqu’aux résultats. Alors le rapport est divisé de la manière

suivante :

Rawdha Mabrouki

3

Chapitre I : est une présentation générale du contexte de projet. Il décrit ainsi la société

Cynapsys puis les formalismes et méthodologies adoptés, enfin la conduite de projet.

Chapitre II : décrit l’état de l’art. Il est consacré à l’étude théorique du contexte de

travail. Dans ce chapitre nous allons définir les systèmes d’information de gestion

d’entreprise, puis une étude fonctionnelle de l’ERP Microsoft Dynamics Ax en tant que

solution de gestion d’entreprise industrielle. Dans un deuxième lieu nous allons analyser

le métier de maintenance et des systèmes de gestion de maintenance. Puis nous allons

analyser les solutions GMAO commercialisés. Enfin nous allons finir par la

problématique du projet.

Chapitre III : présente l’étude préalable. Il constitue la spécification des exigences du

futur module. Nous allons clôturer le product backlog. Enfin nous allons présenter

l’environnement technique et logicielle de maniérer brève.

Chapitre IV : décrit l’élaboration du Sprint 1 de conception et développement du sous-

module gestion des équipements industriels.

Chapitre V : décrit l’élaboration du Sprint 2 et 3 de conception et développement de

sous-module gestion des ordres de travail et contrats de maintenance.

Le rapport s’achèvera alors en rappelant les réalisations essentielles de notre travail et les

perspectives ouvertes.

Rawdha Mabrouki

1

Chapitre I. Contexte de Projet

I.1. Introduction

Dans ce premier chapitre, nous allons expliquer le contexte de projet. Cette partie constitue

alors une présentation générale du cadre de stage. En premier lieu, nous allons présenter

l’organisme d’accueil. Dans un deuxième temps, nous présenterons un aperçu du projet.

Troisièmement nous allons spécifier les différents moyens et méthodes choisies et appliquées

durant ce stage. Enfin nous allons détailler la conduite de notre travail.

I.2. Présentation de l’organisme d’accueil

En tant qu’élève ingénieur en Ingénierie Informatique à SESAME l’École Supérieure des

Sciences Appliquées et de Management, nous avons cherché un stage qui convient, notre

formation, nos ambitions et nos centres d’intérêt. Nous avons réalisé une investigation autours

des entreprises spécialisés dans le développement de logiciel, en Tunisie. Cynapsys est une

entreprise travaillant dans le domaine de développement des systèmes d’informations [W1].

L’entreprise est en partenariat avec notre université SESAME. Elle offre des projets de fin

d’étude dans des sujets différents. Nous avons choisi l’un des sujets particuliers :

développement d’un module de gestion des activités de maintenance de l’entreprise industrielle.

Cynapsys IT Hotspot en bref

Cynapsys est une ESN1, Fondée en 2004 en Tunisie. Elle est une entreprise de prestation de

services en technologie de l’information. Elle est spécialisée dans le domaine de l’assistance et

le développement spécifique de logiciel pour la télécommunication, les équipements, la finance

et l’industrie [W1]. Le groupe Cynapsys conçoit, développe et déploie des solutions

applicatives métiers à travers ses locaux à Paris, Frankfurt, Alger, Tunis et bientôt Abidjan

[W2]. Ayant acquis une grande expérience dans la gestion des projets off-shore et Near-

shore2. Cynapsys est totalement exportatrice [W1]. En effet, elle a développé une bonne

connaissance du marché européen, principalement la France et l’Allemagne [W2]. Elle s’appuie

sur la puissance des normes internationales. Depuis 2007, des décisions de la direction ont été

1Voir glossaire

2Voir glossaire

Rawdha Mabrouki

2

prises en vue de la certification de management de la qualité CMMI3 niveau 2 et 3 et ISO 9001

- v 20084, afin d’optimiser ses processus internes et de donner à ses clients le meilleur rapport

qualité/prix [W1]. Elle est Microsoft et Oracle Partner. Ensuite elle est l’une des rares

entreprises, membre de l’union internationale de Télécom. Le management de l’entreprise

adossé à ces compétences a permis à Cynapsys d’avoir la confiance de plus de 60 clients de 14

pays à travers le monde [W1].

Directions de Cynapsys Tunis

Cynapsys est organisée en trois directions : une direction commerciale, une direction technique

et une direction administrative. La direction technique comporté trois principaux pôles la figure

ci-dessous illustre les pôles de Cynapsys Tunis.

Le pôle J2EE& Open source a pour tâche la réalisation des applications sur demande en utilisant

la technologie Java/J2EE.Et le pôle systèmes embarqués a pour rôle le développement des

applications embarquées5. Enfin le pôle Microsoft .Net, dans laquelle nous avons menu notre

travail. Ce pôle est chargé du développement des applications en utilisant la technologie.Net et

le développement spécifique autour de l’ERP Microsoft Dynamics Ax.

Produits de Cynapsys Software Engineering

Cynapsys est un acteur majeur dans le secteur de l’ingénierie informatique [W2]. Elle vend des

solutions pour les PMI et PME tel que LEORP, SIEC [W1] etc. Par exemple LEORP est un

PGI qui fournit des fonctions automatisées, avec une dimension collaborative, une structure

modulaire et un paramétrage personnalisé des outils de reporting et d’aide à la décision. Ensuite,

le logiciel SIEC est le premier véritable système d’information pour l’Ecoconception6. [W1].

3 Voir glossaire 4Voir glossaire. 5Voir glossaire. 6Voir glossaire

Figure I-1 : Pôles de Cynapsys [W1]

Rawdha Mabrouki

3

Organigramme d’une ESN

Cynapsys est gérée par son directeur général Mr Imed Ammar. Elle suit l’organisation d’une

ESN. Une ESN est composée des directeurs techniques, des chefs de projet et un groupe qui

fournit un soutien technique qui comprend les fonctions principales.

Les fonctions principales sont généralement, le support système, la sécurité, l’assistance clients,

l’administration de la base de données, le support Web, développement des applications et des

responsables assurance qualité ainsi que des ingénieurs experts et certifiés dans de compétences

spécialisées. 94 des ingénieurs de Cynapsys sont des consultants [W2].

I.3. Aperçu du projet

Notre projet vise à concevoir et développer un module de gestion des activités de maintenance

d’une entreprise industrielle dit GMAO. Nous pouvons ainsi dire que ce projet consiste à

développer un outil qui permet de gérer le cycle de vie des équipements industriels.

Thème du sujet

Afin d’entourer le contexte de notre sujet, nous devons tous d’abord définir le thème. Dire que

le sujet et sur la gestion de la maintenance industrielle peut confondre. À vrai dire le projet

s’incorpore dans l’informatique de gestion pas l’informatique industriel. L’informatique de

gestion est le domaine de création des méthodes informatiques appliquées à la gestion des

entreprises.

Figure I-2 : Direction technique d’une ESN [W2]

Rawdha Mabrouki

4

Travail demandé

Comme déjà évoquée, dans ce qui précède, ce sujet s’inclut dans le volet de l’informatique de

gestion. Le projet a été proposée par mon encadrant professionnel Mr. Aleddine AZIZ. Ma

mission consiste à développer le module autour de l’ERP Microsoft Dynamics Ax 2012 R3. Le

but est donc de développer une solution personnalisée de Dynamics Ax orienté vers le secteur

industriel. Plus exactement nous devons développer et concevoir les 5 volets du projet en

respectant les contraintes fonctionnelles et de délais.

La gestion des contrats de maintenance,

Planification et ordonnancement des ordres de travail,

Contrôle des coûts,

Reporting, et développement des indicateurs de performance.

Afin de réussir ce projet il faut donc acquérir les bonnes pratiques permettant de développer la

capacité de concevoir et la faculté de résoudre les problèmes rencontrés.

I.4. Méthodologie et formalisme adoptés

Le principe de CMMI assume que le processus de qualité est le chemin vers un logiciel de

qualité (Siegel, 2000). Donc pour obtenir un logiciel de qualité, il faut en maîtriser le processus

d’élaboration. Autrement dit, la livraison des systèmes et logiciel étaient en retard, n’a pas livré

la fonctionnalité demandée par les clients, coûtent plus cher que prévu, et ne sont pas fiables.

Alors des processus de développement sont mis en œuvre afin de guider le cycle de vie du

logiciel (Siegel, 2000). Ainsi pour finaliser notre application avec la réussite nous devons

définir une méthodologie qui distingue les étapes de développement en exploitant au mieux les

principes fondamentaux tel que la modularité, la réduction de la complexité, la réutilisation.

Méthodes agiles

Nous avons adopté une approche de développement s’inspirant des méthodes agiles. De sorte

que nous allons effectuer un développement itératif. Or chaque itératif possède ses objectifs et

doit aboutir à une version stable d’un sous-module. Le développement agile met l’accent sur le

code et moins sur la documentation ainsi qu’il permet de réagir au changement au lieu de suivre

le plan ce qui augmente l’agilité (Rota, 2010). Nous pouvons citer à titre d’exemple des

méthodologies agile tel que l’ASD, FDD, Extreme Programming et Scrum. Scrum sera la

méthodologie adoptée pour notre projet.

Rawdha Mabrouki

5

I.4.1.1 Méthode Scrum

Scrum est une méthode qui s’appuie sur le découpage d’un projet en boîtes de temps, nommées

Sprints. Les Sprints peuvent durer entre quelques heures et un mois (avec une préférence pour

deux semaines). Chaque sprint commence par une estimation suivie d’une planification

opérationnelle ou bilan. Le sprint se termine par une démonstration de ce qui a été achevé et un

bilan. Puis un nouveau sprint démarre dès la fin du précédent (Jerrel Blankenship, 2011). La

figure ci-dessous illustre une étude comparative entre Scrum et Cascade. L’avantage de la

méthode Scrum par rapport à la méthode traditionnelle c’est qu’elle aboutit toujours à la

livraison d’un produit partiel fonctionnel ou un release. Alors, le facilitateur (à la charge de

réduire au maximum les perturbations) spécifie des estimations et bilans de la capacité d’un

sprint. Scrum contient des artéfacts de base : la planification du sprint, le Backlog du produit et

le Backlog du sprint et le revue sprint enfin le rétrospectives sprint (Jerrel Blankenship, 2011).

(1) Backlog du produit

Le Backlog du produit est l’artefact le plus important de Scrum. C’est l’ensemble des

caractéristiques fonctionnelles et techniques qui constituent le produit souhaité. Les

caractéristiques fonctionnelles sont appelées des histoires utilisateur (User Story) et les

caractéristiques techniques sont appelées des histoires techniques (Technical Story) [W3]. Le

Product Backlog évolue tout au long de la vie du produit. (Jerrel Blankenship, 2011).

(2) Revue Sprint

La revue de sprint ou bilan a lieu à la fin du sprint. Son but est de présenter les User Stories

achevées pendant le Sprint. C’est une réunion pendant laquelle une démo est exécutée (Jerrel

Blankenship, 2011).

Figure I-3 : Comparaison entre Cascade et Scrum [W3]

Rawdha Mabrouki

6

(3) Rétrospectives Sprint

La revue de Sprint permet d’inspecter le produit. La rétrospective de Sprint suit la revue de

Sprint. Elle permet d’inspecter et d’adapter le processus et l’environnement (Jerrel

Blankenship, 2011).

La figure ci-dessus illustre les artéfacts de Scrum. Alors le Sprint Backlog définit la liste des

tâches à faire à l’intérieur d’un sprint. Nous n’allons pas réellement travailler directement avec

un Product Owner, mais nous allons garder en tête que les livrables répondent exactement à ce

que le client exige.

I.4.1.2 Justification du choix

Le choix de la méthode Scrum a été dû à un certain nombre de critères conduisant à favoriser

une méthode à risque :

Absence d’un cahier des charges client formel, ce qui augmente les risques du projet.

Besoins fonctionnels difficiles à couvrir,

Métier de maintenance très lourd fonctionnellement et un volume fonctionnel

nécessitant un travail modulaire à plusieurs itérations afin de valider la version finale.

Des exigences fonctionnelles et de qualité, à respecter objectivement tout le long du

projet.

Ces raisons et autres, une démarche à risque telle que Scrum, se montre bien favorable pour

couvrir la difficulté du projet.

Méthode de conception

La qualité et la cohérence du produit réalisé au développement dépend de la conception. Des

méthodes de génie logiciel ont alors été développées afin de guider le concepteur dans sa tâche

(Siegel, 2000). Pour bien mener à notre projet, nous avons choisi la méthode de conception

orientée objet. Le plus grand avantage de cette méthode est qu’elle permet de structurer un

système sans centrer l’analyse uniquement sur les données ou uniquement sur les traitements

Figure I-4 : Processus Scrum [W3]

Rawdha Mabrouki

7

mais sur les deux à la fois. Une telle approche a pour but de modéliser les propriétés statiques

et dynamiques du système (Nathalie Lopez, 2000). Nous allons donc utiliser le modèle orienté

objet pour définir et expliciter les diagrammes du formalisme UML, diagramme de cas

d’utilisation, diagramme de séquence, d’activité, d’état-transition et de classe.

Formalisme adopté

Afin de développer le cahier des charges et puis concevoir notre module, nous allons utiliser

des formalismes normalisés et adaptés à notre besoin. Le formalisme offre une description

indépendante de la plateforme ou technologies.

I.4.3.1 Formalisme UML

UML est le langage standard de modélisation des systèmes. Il fournit un ensemble des

diagrammes pour représenter l’aspect statique et dynamique d’un système (Nathalie Lopez,

2000). La figure I-5 illustre les digrammes d’UML. Le design des interfaces utilisateur du

module dépend des cas d’utilisation détaillés et des diagrammes de séquence.

I.4.3.2 Formalisme BPMN

Le Business Process Model and Notation (BPMN) est une notation graphique standardisée qui

permet de modéliser les processus métier d’une entreprise. Nous allons utiliser ce formalisme

afin de concevoir le flux de travail.

I.5. Conduite de projet

La clé principale de réussite d’un projet avec la définition de la méthodologie de gestion de

gestion de projet et le bon planning (Siegel, 2000). En effet, le planning aide à bien subdiviser

le travail et séparer les tâches à réaliser. Il offre une meilleur estimation et gestion de temps

nécessaire pour chaque tâche (Bourque, 2014). En effet, il donne assez de visibilité qui permet

d’estimer la date approximative d’achèvement des activités les plus importantes (Siegel, 2000).

Nous avons utilisé le diagramme de Gantt pour bien visualiser le diagramme de temps relatif à

notre méthodologie de travail. Nous avons donc estimé de réaliser notre module GMAO dans

Figure I-5 : Diagrammes UML (Nathalie, 2000)

Rawdha Mabrouki

8

une durée de 6 mois, démarrant de premier février jusqu’à fin juillet. Cependant, la planification

est prévisionnelle et peu importe la façon dont un projet a été planifier, il y aura toujours des

changements sur la route.

Gantt Chart facilite la représentation graphique de l’avancement d’un projet. Nous avons utilisé

ce diagramme afin de planifier de façon optimale et de communiquer le planning établi. La

figure I-6 illustre le diagramme de Gantt prévisionnel de notre projet.

I.6. Conclusion

Nous avons présenté dans ce chapitre l’organisme d’accueil. Puis nous avons donné un aperçu

sur le sujet. Et nous avons énoncé les méthodologies et formalismes à utiliser. Nous avons mené

une étude de la méthode Scrum en tant que Framework de gestion de notre travail. Enfin nous

avons détaillé la conduite de notre projet avec le diagramme de Gant. Dans le chapitre suivant,

nous présentons l’état de l’art de notre module GMAO.

Task Name Duration

définition du projet 15 days

Montée en compétence sur Axapta 8 days

Documentation sur Axapta 1 day

familiaisation avec SCRUM 1 day

Documentation sur les GMAO 4 days

rédaction du chapitre 1 et 2 1 day

élaboration du cahier des charge 20 days?

étude de l'existant 9 days

élaboration du product backlog 2 days?

Elicitation des exigences 6 days?

Planification des itérations 1 day?

Sprint 0 étude technique Axapta 2 days

rédaction du chapitre 2 et 3 3 days?

étude et réalisation du Sprint 1 14 days?

élaboration du Sprint Backlog 1 2 days

spécification des exigences 2 days

conception 5 days

développement 5 days

Validation et rédaction du Sprint 1 1 day?

étude et réalisation du Sprint 2 32 days?

élaboration du Sprint Backlog 2 3 days

spécification des exigences 5 days

conception 15 days?

développment 8 days

validation et rédaction du Sprint 2 1 day?

étude et réalisation du Sprint 3 17 days?

étude et réalisation du Sprint 4 23 days?

04 07 10 13 16 19 22 25 28 02 05 08 11 14 17 20 23 26 29 01 04 07 10 13 16 19 22 25 28 01 04 07 10 13 16 19 22 25 28 31 03 06 09 12 15 18 21 24 27 30 03 06 09 12 15 18 21 24 27 30February 2016 March 2016 April 2016 May 2016 June 2016 July 2016 August 2016

Figure I-6: Diagramme de Gantt prévisionnel

Rawdha Mabrouki

9

Chapitre II. État de l’Art

II.1. Introduction

Dans ce chapitre, nous présentant l’état de l’art de la gestion de maintenance dans une entreprise

industrielle. Premièrement nous allons définir les fonctions clés de l’entreprise et les

intervenants. Puis nous allons définir le métier de maintenance et son processus de gestion.

Deuxièmement nous allons définir le système d’information de gestion d’entreprise, l’ERP et

sa mise en œuvre dans une entreprise en appuyant sur Dynamics Ax. Ensuite. Enfin nous allons

définir la GMAO en tant qu’outil stratégique pour l’entreprise industrielle. Finalement nous

allons étudier l’existant et présenter la problématique.

II.2. Entreprise industrielle

Le terme ‘Entreprise’ se définit comme une collection d’organisations collaboratives et qui

achèvent un ensemble des résultats afin d’apparaitre un seul but fondamental qui consiste à

dégager un certain niveau de rentabilité, plus ou moins élevé (Fayol, 1916). Une entreprise est

un système adaptatif complexe7. Elle suit une stratégie et une politique et un plan d’action

(Fayol, 1916). Afin de mesurer sa performance l’entreprise doit définir sa propre vision et CSF

(Critical Success Factors). Puis elle peut comparer son CSF par rapport au résultat qu’elle

aboutit en utilisant les mesures et métriques. Elle doit après prendre des décisions suivant cette

comparaison. Les fonctions clés qui règlent les activités de l’entreprise industrielle sont :

ressource humaine comptabilité et finance commerciale et marketing production et

technique direction recherche et développement et logistique et achat.

Modèle organisationnel

L’organisation de l’entreprise est constituée d’un CEO, manager, agent de maîtrise et

opérationnel. Le CEO élabore des plans à long terme, appelé plans stratégiques. Ils définissent

la mission et les objectifs de l’entreprise (Shelly, 2012). Le manager fourni une orientation, et

rétroaction sur le rendement aux superviseurs et examine les résumés (Shelly, 2012). Le chef

d’équipes est chargé de superviser les employés. Ils coordonnent les tâches opérationnelles,

7Voir glossaire

Rawdha Mabrouki

10

prennent les décisions, et veillent à fournir les bons outils. Ils ont besoin de connaissance des

états des fonctions de vente ou de production (Shelly, 2012). Les Employés opérationnels sont

les responsables de déroulement des fonctions de l’entreprise. Ils utilisent le système

d’information pour entrer et recevoir des informations (Shelly, 2012).

Le modèle organisationnel de l’entreprise détermine la localisation et la répartition du pouvoir

entre les personnes. La figure ci-dessus illustre une pyramide qui structure un exemple de

modèle organisationnel.

Mesure de performance de l’entreprise

Les managers et CEO veulent améliorer l’efficience des fonctions. Elle est définie par des

objectifs fixés tout en réduisant le coût global. Les indicateurs et mesures les aident à prendre

des décisions d’amélioration. Ils existent quatre types de mesure : KRI, RI, PI et KPI. Les

(KRI) clés de résultat disent comment les fonctions ont été réalisé dans un perspective ou facteur

du succès critique. Puis les (RI) indicateurs de résultat disent ce qui été réaliser. Les (PI)

indicateurs de performance disent que faire. Enfin la (KPI) clés de performance « est une

donnée quantifiée qui mesure l’efficacité de tout ou partie de processus par rapport à une

norme, plan, ou un objectif déterminé dans le cadre d’une stratégie » (DAVID).

L’entreprise industrielle utilise l’une de ces indicateurs afin de prendre des décisions de long

ou court terme. La figure ci-dessus illustre la relation de ces indicateurs. Elle représente un

oignon, donc à chaque fois que nous pelons les couches nous pouvons trouver plus

d’informations. Les couches présentent les informations KRI, RI et PI et le noyau constitue les

KPIs.

Figure II-1 : Exemple d’hiérarchie organisationnel (Shelly, 2012)

Figure II-2 : Relation entre KPI, KRI,RI et PI

Rawdha Mabrouki

11

II.3. Analyse du métier maintenance

Dans cette partie nous allons expliquer les différents aspects de la maintenance industrielle en

tant que fonction stratégique de l’entreprise. Nous allons situer la maintenance par rapport à

son environnement et identifier ses processus. Nous allons avant tout définir l’objet de

maintenance qui est l’équipement.

Équipements industriels

Un équipement est une machine que l’entreprise possède et utilise dans les processus de

production. Ils existent deux types d’équipement : équipement spécifique qui est critique et

équipements généraux. Chaque usine à ses propres machines, sans elles, pas de production,

qu’elles coupent, percent, assemblent ou emballent. Les machines de production sont

caractérisées par leur capacité et leurs indicateurs :

Taux d’unité produit,

Heures de travail total,

Temps d’arrêt (Downtime),

Temps d’inactivité (Idle time),

Temps de fonctionnement (Running time).

L’équipement industriel est défini par une description de l’arborescence de son emplacement

géographique et une description détaillé de ses pièces détachés (Bufferne, 2006). De peur que

les pannes des équipements peuvent causer des productions inutilisées, des livraisons tardives,

des heures supplémentaires pour compenser la perte de production afin répondre à des

livraisons promises sur temps, et des ventes perdues à la suite de produits non pas livrés à temps,

il faut réaliser la maintenance préventive et corrective des équipements.

Fonction maintenance industrielle

La maintenance est une fonction stratégique dans les entreprises mais catégorisé parmi les

activités non productives.

II.3.2.1 Définition de la fonction maintenance

D’après (NF EN 13306 X 60-319)8 la maintenance est un « Ensemble de toutes les actions

techniques, administratives et de management durant le cycle de vie d'un bien, destinées à le

maintenir ou à le rétablir dans un état dans lequel il peut accomplir la fonction requise ».

8Voir glossaire

Rawdha Mabrouki

12

II.3.2.2 Enjeux de la maintenance pour l’entreprise

La maintenance à diverses missions. Premièrement la réduction du rapport dépense de

maintenance/ quantité et qualité de service rendu (AFNOR, 2016). Puis le rôle de la

maintenance est de gérer le patrimoniale. En effet la conservation de la valeur du patrimoine,

voire son augmentation, est souvent liée à la qualité de la maintenance. Ensuite la maintenance

affecte les aspects commerciaux et le respect de la réglementation et sécurité et la protection

des individus contre les accidents. Enfin la maintenance a des enjeux économiques.

Comme le montre la figure ci-dessous, la masse financière déployée pour la maintenance

représente 4% de chiffre d’affaire de l’entreprise (Marc St-Marseille, 1997). Ainsi que 6

milliards des coûts sont liés à l’externalisation de la maintenance d’après une étude réalisée en

2010 pour une entreprise.

Rôles et responsabilités

Les intervenants dans les activités de maintenances sont souvent les profils métiers de

maintenance ainsi que les demandeurs de maintenance. Les métiers de maintenance sont : le

manager de maintenance, chef de groupe de maintenance, superviseur de maintenance,

directeur de maintenance, coordinateur de maintenance, ingénieur maintenance, planificateur

de maintenance, ingénieur fiabilité et gestionnaire de maintenance etc (AFNOR, 2016). Afin

de simplifier la définition des acteurs. Nous pouvons les classées par rôle et responsabilité. Ce

sont alors le responsable maintenance, technicien de maintenance, chef section et chef d’équipe

de maintenance.

Formes de maintenance

Il existe trois grandes formes de maintenance : la maintenance corrective ou curative, la

maintenance préventive PM, et la maintenance améliorative. En Effet La politique de

maintenance conduit, en particulier, à faire des choix entre la maintenance préventive et/ou

corrective, systématique ou conditionnelle, maintenance internalisée et/ou externalisée. La

Figure II-3 : Part de la maintenance dans le CA (Marc St-Marseille, 1997)

Rawdha Mabrouki

13

figure ci-dessus illustre un logigramme qui permet de prendre les décisions relatives aux choix

de forme de maintenance ainsi que les actions relatives à chaque forme.

II.3.4.1 Maintenance améliorative

La maintenance améliorative reprend toutes les activités qui visent à modifier et adapter

l’équipement. Ceci afin d’améliorer la productivité, la qualité, la sécurité, la fiabilité, la

maintenabilité, la mise en conformité et la durabilité de l’équipement (AFNOR, 2016).

II.3.4.2 Maintenance corrective

La maintenance corrective est l’ensemble des tâches effectuées suite à une anomalie d’un

équipement. Ces anomalies induisent une perte mineure ou majeure de sécurité, de respect de

l’environnement ou de production (arrêt ou ralentissement de l’installation, perte de matière

première, mobilisation de plus de personnel) (AFNOR, 2016). Mais si la criticité de

l’équipement est faible et que la défaillance n’engendre pas un impact important (sécurité,

production, environnement), alors le responsable de production peut faire le choix de s’orienter

vers du correctif planifié (Bufferne, 2006) (AFNOR, 2016). Donc ils existent deux types de

maintenance corrective : le correctif urgent et le correctif planifié.

II.3.4.3 Maintenance préventive

La maintenance préventive reprend toutes les actions menées afin d’anticiper et d’éviter tout

anomalie sur l’équipement. Ces actions de maintenance sont soit basées sur un calendrier ou

une périodicité d’usage9 (préventif systématique). Exemple : vidanges sur compresseurs,

9 Voir glossaire

Figure II-4 : Formes de maintenance (AFNOR, 2016)

Rawdha Mabrouki

14

changement systématique de roulements de laminoirs. Soit sur des observations subjectives ou

mesurables (conditionnel ou prévisionnel). Exemple : surveillance du bruit et des vibrations

d’un équipement, analyses d’huile et mesures thermographiques (AFNOR, 2016) (Marc St-

Marseille, 1997).

Gestion de maintenance

Le management de la maintenance concerne les activités de direction qui déterminent les

objectifs, la stratégie et les responsabilités concernant la maintenance (Marc St-Marseille,

1997). Il est nécessaire d’avoir une vision globale de ce qu’apporte la maintenance. En effet la

nécessité d’optimiser l’efficacité de la maintenance impliquera l’utilisation plus fréquente

d’indicateurs pertinents pour mesurer la performance de la maintenance et une meilleure prise

en compte des notions économiques (Mobley, 1999).

II.3.5.1 Outils de gestion de maintenance

Tout comme l’intervention technique de maintenance, l’organisation et la gestion des activités

de maintenance nécessitent l’emploi d’outils d’usage et de natures différentes tels que les outils

mathématiques, les stratégies de maintenance, outils informatiques …

(1) Outils mathématiques

La probabilité, les lois statistique, l’algèbre des événements et l’analyse markoviennes

(stochastique de prédiction) (Mobley, 1999) sont des outils mathématiques permettant de

choisir les politiques de maintenance les mieux adaptés à chaque type d’équipement, déterminer

les périodes d’intervention et de connaitre la fiabilité, maintenabilité, disponibilité…

(2) Stratégies de maintenance

TPM, AMDEC et LCC10 sont des stratégies de maintenance. Les documents, les synoptique et

les logigrammes sont des outils organisationnels. Ce sont dit aussi outil de planification. Ils

permettent de faciliter la prise de décisions, la mise en œuvre de la maintenance préventive ou

l’organisation des interventions.

(3) Outils informatiques

Les systèmes GMAO, EAM sont des outils pour la gestion des éléments maintenus, des

ressources utilisées et des budgets, ou pour l’aide à la décision tels que les systèmes experts.

10 Voir glossaire

Rawdha Mabrouki

15

II.3.5.2 Rapports de maintenance

Les rapports de maintenance sont illustrés dans l’annexe A. Ils sont émis à partir des documents

enregistrés, des rapports de pointage journalier des interventions. Les documents enregistrés

sont les fiches de demande, de l’équipement, et d’ordre de travail. Nous distinguons ainsi le

rapport hebdomadaire de maintenance, le rapport mensuel par équipement, le rapport mensuel

du service de maintenance qui est la consolidation des rapports ci- avant enfin le bilan annuel

de maintenance (Mobley, 1999). Nous pouvons émettre des indicateurs de performance de

maintenance : le taux de respect de planification, taux du préventive, corrective, les KPI’s de

coût de maintenance.

Processus de maintenance

Un processus de maintenance est un enchaînement d’activités contrôlées ou interactives (Marc

St-Marseille, 1997), selon une démarche bien définit. Cette démarche est constituée

généralement de 6 grandes phases. Ce sont la demande, l’identification de travail, la

planification, l’ordonnancement de travail, l’exécution de travail, l’enregistrement de

l’historique en fin l’analyse. Certains processus sont automatiques d’autres sont manuels.

II.3.6.1 Demande de travail

La demande exprime le besoin de réalisation de la maintenance corrective ou préventive ainsi

que toute externalisation de la maintenance ou de la demande pointue exprimée comme la

maintenance améliorative, (Marc St-Marseille, 1997) un devis sur un équipement, des travaux

lourds etc.

II.3.6.2 Identification de travail

L’identification de travail constitue la phase de déclenchement, la préparation et la validation.

(1) Déclenchement de travail

Le déclenchement représente une signalisation souvent automatique d’un problème (défaillance

ou panne) ce qui se traduit par un ordre de travail.

(2) Phase de préparation et validation

Toutes les DT font objet de préparation et ce même s’il s’agit d’un simple resserrement de PE

de vanne (Mobley, 1999). Une première étude de l‘équipement, consistant en sa décomposition

hiérarchique, de l’analyse fonctionnelle à l’AMDEC (Marc St-Marseille, 1997). La DT est

corrigée et validé par le prestataire de services de maintenance et renvoyée au demandeur qui

exprime les disponibilités ou son accord pour la date de l’intervention.

Rawdha Mabrouki

16

II.3.6.3 Planification et lancement

La planification et le lancement consécutif de l’intervention se font suivant la disponibilité des

techniciens dont les compétences sont nécessaires pour effectuer cette intervention (ses

compétences sont identifiées dans le type d’intervention) et suivant le planning de la production

(Marc St-Marseille, 1997). La demande d’intervention complétée de la date précise d’exécution

est communiquée à l’opérateur en tant qu’ordre de travail (Marc St-Marseille, 1997).

II.3.6.4 Ordonnancement et approvisionnement

Donc cette étape le responsable de maintenance affecte les travaux aux différentes sections de

réalisation des travaux. Notons aussi que certaines DT peuvent être bloquées soit parce que

l’intervention ne peut faite qu’à l’arrêt de l’équipement. Elles sont alors bloquées au niveau de

cette unité, jusqu’à ce que les conditions de l’intervention soient réunies (Marc St-Marseille,

1997). Ensuite l’équipe de maintenance prend en compte le travail. La prise en compte

représente un moment important pour les calculs des indicateurs élémentaires pour la gestion

de maintenance et notamment pour l’exploitation du retour d’expérience comme par exemple

le temps de la réparation (Marc St-Marseille, 1997).

II.3.6.5 Diagnostic et l’expertise

Le diagnostic et l’expertise de panne concerne la localisation et d’identification de la cause ainsi

que les actions conduisant à sa réparation. Il est réalisé par l’opérateur de maintenance

intervenant sur l’équipement, en se basant sur le premier diagnostic fait par l’opérateur de

production pendant la création de la demande d’intervention (Marc St-Marseille, 1997).

II.3.6.6 Approvisionnement, achat et exécution

Suite au manque d’information que la défaillance de l’équipement dans la maintenance

corrective, l’approvisionnement ne peut se faire qu’après avoir identifié la panne et sa cause ce

qui amène à identifier les besoins en outils et pièces de rechange nécessaires pour réaliser la

réparation (Mobley, 1999). Puis l’exécution représente les actions de réparation de

l’équipement en panne dans la maintenance corrective. Après avoir effectué l’intervention sur

l’équipement donné, le technicien remplit le rapport d’intervention qui sert à l’exploitation du

retour d’expérience Enfin l’opérateur de production peut vérifier et contrôler l’équipement.

II.4. Systèmes d’information de gestion d’entreprise

L’entreprise industrielle est vue comme un système décomposé en trois sous-systèmes en

interaction. Ce sont le système opérant, le système d’information et le système de pilotage.

Rawdha Mabrouki

17

Le système d’information joue le rôle de mémoire entre les deux autres. Il est défini comme

« un ensemble organisé de processus qui permet de collecter, stocker, traiter et distribuer de

l’information. » (Chambon, 2016). Le système d’information constitue l’informatisation des

processus métiers de l’entreprise. Le processus est exécuté par des acteurs humains ou des

automates utilisant des ressources. Nous citons des exemples de processus : la saisie, stockage,

transmission, recherche, manipulation et restitution.

Inconvénients des SI traditionnels

L’inconvénient majeur des systèmes d’information traditionnels, c’est qu’ils manquent la

capacité d’intégration entre différentes applications isolées. En réalité, une organisation ne peut

pas fonctionner comme des îlots de différents départements. En effet les données de

planification de la production sont nécessaires pour le service des achats. Et les détails d’achat

sont nécessaires pour le département des finances et ainsi de suite (Thomas, 2001).

Entreprise Ressource Planning

Un ERP est un « logiciel qui permet de gérer l’ensemble des processus d’une entreprise en

intégrant l’ensemble des fonctions de cette dernière comme la gestion des ressources humaines,

la gestion comptable et financière, l’aide à la décision, et aussi la vente, la distribution,

l’approvisionnement, la commerce électronique » (Chambon, 2016).

II.4.2.1 Fondateur d’un ERP

Le principe fondateur d’un ERP est de construire les fonctions de l’entreprise, par exemple une

application de paie ou comptabilité, de manière modulaire tout en partageant une base de

données unifiée (Thomas, 2001). Cela crée une différence importante par rapport à la situation

préexistante d’un système d’information, car les différentes fonctions de l’entreprise étaient

gérées par une multitude d’applications dédiées et hétérogènes dite modules. Ces modules sont

utilisés pour gérer les " 8 M " (Man ou Homme, Matériel, Machine, Money ou Argent, Méthode,

Minute, Management et Marketing) (Okungbowa, 2015). Avec l’arrivée de l’ERP, les données

sont désormais standardisées et partagées entre les différents modules, ce qui élimine les saisies

multiples et évite l’ambiguïté des données multiples de même nature (Thomas, 2001). Ceci

permet un accroissement considérable de la fiabilité des informations puisque la source des

données est unique, d’où une réduction des délais et des coûts de traitements. L’autre principe

qui caractérise un ERP est l’usage systématique de ce qu’on appelle un moteur de workflow

(Simha, 2011), et qui permet, lorsqu’une donnée est entrée dans le système d’information, de

Rawdha Mabrouki

18

la propager dans tous les modules du système qui en ont besoin, selon une programmation

prédéfinie (Thomas, 2001).

II.4.2.2 Implantation d’un ERP

Dans la classification des logiciels, l’ERP est un package destiné, a priori, à tous les secteurs, à

toutes les fonctions. Les adaptations nécessaires se fait par paramétrage (Thomas, 2001). Or

l’implantation d’un ERP dans une entreprise porte des avantages ainsi que des inconvénients.

(1) Avantages de l’implantation d’un ERP

L’implantation d’un ERP au niveau d’une entreprise et la seule solution pour avoir une intégrité

et unicité du système d’information. Or cette unicité garanti la cohérence et l’homogénéité des

informations. Encore la communication interne et externe est facilitée par le partage du même

système ce qui permet une meilleure coordination des services et donc meilleur suivi des

processus (Thomas, 2001) (Simha, 2011).D’une autre coté, les entreprises multinationales

apprécient la mise à leur disposition d’un outil multilingue et multidevises (Simha, 2011). Pour

les entreprises gérant de nombreuses entités parfois géographiquement dispersées, un progiciel

peut normaliser la gestion de ses ressources humaines (Simha, 2011). Puis les coûts de mise en

œuvre, de déploiement, de formation et de maintenance des systèmes dispersés coûtent plus

cher que celle-ci réaliser sur un système unique et les délais de mise en œuvre sont ainsi

minimiser grâce à l’implantation d’un ERP. Enfin l’avantage des indicateurs de performance

de l’ERP c’est qu’ils permettent de maîtriser les coûts et d’évaluer le succès de l’organisation.

Ils sont plus fiables que lorsqu’ils sont extraits de plusieurs systèmes différents (Thomas, 2001).

(2) Inconvénients d’implantation d’un ERP

Les ERP ne sont pas exempts d’inconvénients. Ils sont difficiles et longs à mettre en œuvre car

ils demandent la participation de nombreux acteurs. Dans d’autres cas ils sont relativement

rigides et délicats à modifier et mettre en œuvre. Non seulement qu’il coûte cher, il est aussi

difficile d’appropriation par le personnel de l’entreprise (Thomas, 2001). En fin les ERP

nécessitent une maintenance continue (Thomas, 2001).

II.4.2.3 Modules ERP

Chaque module ERP se concentre sur une zone de processus métier. Un module est une brique

logicielle. Ils représentent la séparation des préoccupations (Thomas, 2001). Ce qui permet

d’améliorer la maintenabilité en appliquant des limites logiques entre les composants. Les

modules sont généralement incorporés dans l’ERP par le biais d’interfaces. Quel que soit le

vendeur de l’ERP, propriétaire ou libre, nous trouvons les mêmes modules de base.

Rawdha Mabrouki

19

Généralement dans un ERP nous trouvons les modules GRH, de gestion financière, modules

SCM, modules de gestion des projets enfin les modules CRM.

II.4.2.4 Vendeurs des ERP

Un ERP s’accomplit grâce à des logiciels comme SAP et Ax qui sont constitués d’un package

d’applications que les entreprises utilisent pour stocker des données et gérer ses processus. Nous

trouvons deux types d’ERP : les ERP open source et les ERP propriétaires. Les ERP open

source sont développées sur mesure par des ESN ou cabinet de conseil, leur implémentation et

moins coûteuse car ils ne nécessitent pas une licence. Les avantages des ERP open source est

qu’ils sont flexibles et spécifique à l’entreprise, exemple OpenERP, OFBiz, Compiere et

Dolibarr. L’inconvénient de ces solutions c’est qu’ils n’arrivent pas à la maturité requise afin

de gérer les processus métier de l’entreprise de manière efficace. Outre que ces ERP, les

progiciels ERP sont vendu par Oracle (People Soft), BAAN, JD Edwards et Siebel, et autre

Selon une étude du cabinet de conseil américain Panorama Consulting effectué en 2010, SAP

est le leader incontesté en matière d’ERP, bénéficiant d’une part de marché de 22%.

La figure ci-dessous illustre le classement des vendeurs de solution selon l’étude. Alors, Oracle

maintient une part de marché de 15%, tandis que Microsoft arrive à 10%. Le reste est réparti

sur d’autres fournisseurs de systèmes ERP [W6].

(1) SAP GP

SAP est développé par SAP AG, une société de logiciels allemande fondée en 1972 par cinq

anciens employés d’IBM (Okungbowa, 2015). Les modules basiques de SAP sont FI et CO

respectivement Financial et Controlling.Le module FI consiste à d’autres sous-modules qui

incluent Genral Ledger, Accounts Receivable, Accoutns payable, Bank Accounting, Asset

Accounting, Special Purpose Ledger, Travel Management. Enfin le module CO est composé

des modules : Cost Element, Cost Center, Internal Order, Activity based costing, product

costing, profitability, Analysis et profit Center.

Figure II-5 : Charte de Sélection des ERP propriétaires

Rawdha Mabrouki

20

(2) Microsoft Dynamics

Dynamics est une gamme de progiciels de gestion d’entreprise conçue par Microsoft. Cette

gamme, qui fut également connue sous le nom de Project Green (Luszczak, 2015). Il est le

successeur de l’ancienne famille de logiciels destinée à la gestion d’entreprise, Microsoft

Business Solutions (Luszczak, 2015). Il est présent dans 28 pays pour un effectif de 4 000

salariés. Il inclut les logiciels suivants (Blokdijk, 2015), (Luszczak, 2015): Dynamics Ax ,

Dynamics GP (anciennement Great Plains), Dynamics NAV (anciennement Navision) et

Dynamics SL (anciennement Solomon)

II.4.2.5 Comparaison entre SAP et Dynamics Ax

Vue que SAP est considérer le leader de marché depuis des années, nous avons préféré

d’effectuer une étude comparative avec lui par rapport à Dynamics Ax. Ax vient d’être l’ERP

le plus célèbre et utiliser par les moyennes et grandes entreprises. En effet, le coût d’acquisition

et de maintenance, temps de mise en œuvre sont moins élevés chez les entreprises qui

implantent Ax. La personnalisation est plus facile avec Axapta. Puis le fait que SAP a des

fonctionnalités plus solides qu’AX était vrai dans le passé, et pour la dernière version AX 2012

R3, il peut rivaliser directement avec SAP [W6]. Le tableau ci-dessous illustre une comparaison

entre SAP et Ax.

Tableau II-1 : Tableau comparatif entre SAP et Ax [W6], (Blokdijk, 2015)

SAP Business All-in-One Microsoft Dynamics Ax

Coût total d'acquisition De nombreux composants

nécessitent des licences add-on

coûteuses.

Toutes les fonctionnalités de

Microsoft Dynamics Ax sont

incluses dans une seule licence.

Temps de mise en œuvre Temps de mise en œuvre plus long. Temps de mise en œuvre est plus

court.

Maintenance Maintenance démarre à 19% avec

une augmentation de l’inflation

annuelle.

Maintenance démarre à 16%, sans

augmentation de l’inflation.

Expérience utilisateur

UX11

Expérience utilisateur propriétaire à

SAP.

Expérience utilisateur identique

aux autres technologies Microsoft

Interopérabilité bureau À ajouter, add-on. Intégré, buit-in.

Plate-forme

codage SAP HANA-centric (ABAP)

+ java Bolt-on solution.

Windows, SQL, Microsoft Azure

.NET (C # et X ++).

Intelligence d’entreprise Exige des licences supplémentaires. Intégré dans SQL Server.

11 Voir glossaire

Rawdha Mabrouki

21

La comparaison est sur les champs de coût totale et temps de mise en œuvre, la complexité de

maintenance, l’expérience utilisateur, la plateforme et l’architecture …le choix de l’architecture

basé sur Dynamics Ax devient évident. C’est le cas d’une grande compagnie d’énergie, ‘Eneco’

leader dans la production d’énergie verte aux Pays-Bas, travaillant avec plus de 2 Millions de

clients. Cette entreprise veut optimiser sa propre architecture basée sur SAP. Après un audit

effectué sur son SI, une décision est prise, consiste à remplacer son architecture. Ce qui peut

éliminer certains problèmes. Ce sont l’expérience utilisateur compliqué, le chargement lourd

des IHM et les fonctionnalités inutiles. Ensuite une proposition d’une autre architecture doit

s’appliquer après l’investigation sur les autres ERP. Cela a conduit à choisir une solution

intégrée basée sur Ax nommé Umax, offerte par une entreprise nommée ‘Itineris’ travaillant

dans le consulting. La solution a réussi comparé à la précédente. La preuve c’est que la

manipulation B2B12, compliqué des offres de gaz devient plus rapide, simple et efficace. Après

une étude comparative, le processus d’ajout d’un client est fini après 28 minutes avec SAP et

après 10 minutes avec Umax.

Étude fonctionnelle de Dynamics Ax

Nous avons comparé Ax par apport le leader du marché SAP. Et il est bien évident qu’il apporte

une multitude d’avantages qui mène les entreprises à le déployer pour gérer leurs fonctions. Ax

est un ERP générique conçu pour les entreprises de 200 à 7500 utilisateurs (Blokdijk, 2015). Il

soutient les organisations mondiales en gérant plusieurs sites opérationnels par le biais de

Master data et les processus métier. Ainsi que les capacités propres à chaque pays sont gérées

en une seule instance (Blokdijk, 2015). Notamment les entreprises choisissent Dynamics Ax

vue son architecture modulaire présentée au niveau d’annexe B.

II.5. Gestion de maintenance assistée par ordinateur

L’analyse de métier de maintenance effectué montre l’ampleur de la tâche des responsables et

manager de service à cause de la masse énorme d’informations quotidiennes disponibles. Cette

masse d’informations implique des moyens de saisie, de stockage et de traitement que seul

l’outil informatique permet. Dans ce contexte que vient le rôle du GMAO. Par définition un

GMAO (CMMS est l’équivalent anglais), permet le suivi de toutes les activités de maintenance

(AFNOR, 2016). Bref, c’est un progiciel qui aide l’équipe de maintenance dans sa tâche

quotidienne (AFNOR, 2016).

12 Voir glossaire

Rawdha Mabrouki

22

Rôles du GMAO

Il faut se méfier du papier. Car le technicien de maintenance risque facilement d’y ajouter une

annotation importante et d’en perdre la trace. Il peut y avoir un fascicule à la maintenance, le

même imprimé à proximité de la machine, un autre à la production. Il existe aussi un risque de

perdre une trace d’une modification importante qui ne serait notée que dans une des versions.

Le technicien se retrouve ainsi avec plusieurs fascicules différents et il ne sait plus lequel croire.

L’intérêt de la GMAO apparait alors très clairement, les intervenants de maintenance peuvent

encoder toute une série d’informations que ne se trouveront qu’à un endroit : dans la base de

données du GMAO. De cette manière, s’ils modifient, uniquement à la source, plus de soucis

de traçabilité de la documentation. La figure ci-dessus est un diagramme de cause et effet qui

analyse les racines de la mauvaise exploitation des documents et informations de maintenance

et l’absence du GMAO est l’un des racines.

Fonctionnalités de base

Dans la GMAO, nous pouvons donc gérer la liste des pièces détachées en fiches articles, liés

aux équipements et nous pouvons gérer les stocks directement dans différents magasins. La

figure ci-dessus illustre la totalité des fonctions du GMAO exigés par tous types d’entreprises

industrielle. L’une des plus importantes fonctionnalités est l’assimilation des tableaux de bord.

Figure II-6 : Diagramme cause/effet problèmes de papiers (Marc St-Marseille, 1997)

GMAO

Gestion des équipements

Gestion de la maintenance

Préventive

Gestion de la maintenance

Prédictive

Gestion de la maintenance Améliorative

Gestion de la maintenance

Corrective

Gestion des Ordres de

Travail

Rapport et Analyse

Gestion des Contrats

Planification et Ordonnancement

des Ordres de Travail

Figure II-7 : Fonctions du GMAO (R.Keith Mobley)

Rawdha Mabrouki

23

En effet, le management de la maintenance nécessite, pour son responsable, la mise en œuvre

de tableaux de bord appropriés construits à partir d’indicateurs et de ratios pertinents.

II.6. Étude de l’existant

Pour de mieux mener un projet d’informatisation, il convient au préalable de faire une étude

des solutions existantes. Ils existent des solutions GMAO réalisés avec un simple tableur

(Excel). Nous trouvons ainsi une panoplie de logiciels plus ou moins performants. En effet les

solutions commercialisées du GMAO sont proposés par deux types d’éditeurs : des sociétés

spécialisées dans les ERP qui proposent une suite logicielle dans laquelle nous trouvons un

module de GMAO tel que SAP EAM et des sociétés spécialisées dans la gestion de maintenance

tel que MAXIMO Asset d’IBM. Le système d’information de l’entreprise est propulsé autour

de l’ERP Microsoft Dynamics Ax. D’où le nouveau progiciel communiquera avec certains

modules pour garantir la cohérence et l’intégration de la fonction gestion de maintenance avec

les autres fonctions de l’entreprise. Nous sommes en face de deux choix : soit le développement

spécifique ou l’achat d’un logiciel. Ainsi que l’achat nous met entre deux autres choix :

d’intégrer une solution GMAO avec Dynamics Ax, de paramétrer un module Dynamics Ax de

gestion de maintenance.

Intégration d’une solution GMAO

L’une de solution d’implantation d’un GMAO ou niveau de système d’information d’une

entreprise industrielle est d’acheter l’un des produits existants dans le marché. Puis de

l’intégrer. Nous avons choisi les solutions les plus achetés, et les plus performantes : Maximo

Asset Management d’IBM, et eAM d’Oracle. Nous présentons la solution d’Oracle vue qu’elle

est la plus proche de notre projet en termes de fonctions.

II.6.1.1 eAM d’Oracle

La solution eAM d’Oracle pèse bien sur le marché des EAM. Elle offre les modules de gestion

des équipements, des ordres de travail de planification et gestion des coûts d’interventions. Il

fournit un tableau de bord qui affiche des statistiques sur les équipements et les ordres de travail.

Cette page affiche ainsi des chartes qui montrent les statuts des ordres de travails, en cours, en

attente pour planification, en attente pour planification des matériels de maintenance ou achat

de pièces de rechange. De telle façon le manager et responsables de maintenance peuvent savoir

la cause et effet des retards de maintenance (solution, 2015) .

Rawdha Mabrouki

24

La figure ci-dessus illustre le tableau de bord d’Oracle eAM.

II.6.1.2 Inconvénients de l’intégration

Oracle eAM propose différents modules afin de gérer la maintenance. Cependant, ces solutions

coûtent cher, et parfois proposent des fonctionnalités non demandées par le client tel que la

gestion des stocks, gestion d’achat et approvisionnement (déjà existant sur MDX). Des coûts

de support technique et de maintenance s’ajoutent avec le coût d’achat. D’autres parts,

l’intégration d’un progiciel autour du système d’information existant pose les problèmes liés à

l’interopérabilité13 et problèmes de communication avec les autres processus métier de MDX.

Paramétrage d’une solution GMAO sur Dynamics Ax

La première proposition, a posé plusieurs problèmes. D’où il est nécessaire de penser à

s’investir dans le paramétrage d’un module Ax hétérogène. Nous avons donc choisi les

meilleures solutions existantes sur le marché afin de l’étudier : DAXEAM et Dynaway. Nous

allons présenter la solution de Dynaway comme référence.

13Voir glossaire

Figure II-8 : Tableau de bord d’Oracle eAM (solution, 2015)

Rawdha Mabrouki

25

II.6.2.1 Dynaway EAM

Dynaway EAM est une solution de gestion des équipements. Elle propose une multitude de

service de gestion de maintenance : le contrôle de coût, la gestion de maintenance corrective,

la gestion de maintenance conditionnée, la gestion de maintenance préventive, la gestion de

maintenance prédictive, la planification, la manipulation des pièces de rechange. [W8].

Dynaway EAM distingue deux parties : la partie client et la partie fournisseur [W8].

Dynaway EAM manipule les équipements critiques et leurs pièces détachées en tant que objets.

Les objets sont affichés sur la ListPage AllObject. La figure ci-dessus illustre la page AllObject.

Dynaway visualise la liste des équipements en hiérarchie. Ils sont présentés avec leur parent sur

un treeviewdans un FactBox.

II.6.2.1 Inconvénients du paramétrage

L’inconvénient de Dynaway c’est qu’il est très riche de fonctionnalités, parfois compliqué à

comprendre. Et parfois il présente des fonctionnalités inutiles. Ainsi que cette complexité peut

créer des bugs et problème de paramétrage. Bref l’inconvénient majeur de Dynaway EAM c’est

qu’il coûte très chère, d’où la nécessité de développer un module GMAO autour de Dynamics

Ax, qui satisfait le nouveau besoin de l’entreprise.

Tableau de synthèse

À l’issue de cette étude nous constatons qu’il y a une différence au niveau des caractéristiques

de chaque ’une des solutions. Par ailleurs la majorité de solution commercialisée n’est pas en

correspondance avec les critères fondamentaux du GMAO demandé dans notre cas. Nous

pouvons conclure aussi que la solution Dynaway EAM est plus ou moins la plus proches du

GMAO envisagée par rapport au partage de la base de données et d’intégration.

Figure II-9 : Interface List page de Dynaway [W8]

Rawdha Mabrouki

26

Tableau II-2 : Récapitulatif des solutions GMAO étudiées

Solutions commercialisés

Dynaway Eam Oracle eAM

Interface utilisateur Interface commun. Interface ergonomique.

Processus de maintenance Trop de processus automatisés Vision complète sur les processus.

Intégration Intégration et facilitée des tâches

d’interventions.

Problèmes d’interopérabilité avec les

processus existants sur Ax.

Aide à la décision Seulement 5 types de KPI sont

calculés.

Identification de la maintenance adaptée

pour chaque situation et stratégie.

Outil de planification Re-planification dynamique Planification statique.

Coût Coût d’implantation cher avec le

coût de formation.

Vendu en pack de module. Coût dépend du

pack.

Degré de sophistication Très compliqué. Moins compliqué.

Avantages Base de données commune,

référentiel normatif et robustesse

des services de maintenance

prévisionnelle.

Gestion de la garantie et pièces de rechange.

Inconvénients Compréhension difficile des

processus.

Certain processus ne sont pas demandés et

base de données éparpillée.

II.7. Problématique

L’innovation et la stratégie de l’entreprise industrielle dictent le nouveau besoin

d’informatisation de la gestion de maintenance. Le GMAO est un logiciel très répondu. Mais

sa mise en place est coûteuse à plusieurs niveaux : de formation du personnel, problème

d’intégration du module, exigences difficiles à cerner et la mise en place coûteuse

financièrement mais également en termes de temps. Pour remédier à ces différents problèmes,

nous avons besoins de réaliser une étude préalable. Cette étude prendra en considération

l’existant ainsi qu’une capture des besoins exhaustive afin de cerner les fonctionnalités

demandées avec le coût adéquat.

II.8. Conclusion

Dans cette partie nous avons étudié les différents aspects d’une entreprise industrielle. Nous

avons défini comment le système d’information peut être au service de la stratégie de

l’entreprise. Et nous avons présenté comment l’ERP facilite le maintien des processus métier.

Puis nous avons étudié l’aspect fonctionnel de Microsoft Dynamics Ax en tant que système

d’information de gestion d’entreprise. Ensuite nous avons présenté l’importance stratégique du

métier maintenance, qui sera le sujet de notre future analyse et conception. Afin de finir nous

avons étudié les solutions existantes sur le marché. Enfin nous avons évoqué la problématique

de notre projet et qui va être résolu dans le chapitre suivant.

Rawdha Mabrouki

27

Chapitre III. Étude Préalable

III.1. Introduction

Effectuer une étude préliminaire détaillant les principaux concepts en rapport avec la

problématique étudié est un préalable incontournable à la réalisation de tout projet. Dans ce

chapitre nous présenterons l’étude préalable que nous avons élaborée dans le but de réussir les

phases de conception et de développement de notre module. En effet nous allons proposer une

démarche détaillant les étapes de résolution du problème. Dans un deuxième lieu nous allons

proposer notre solution, avec le Backlog produit. Enfin nous allons présenter l’environnement

technique de notre projet.

III.2. Solution Proposée

La décision de choix de GMAO repose sur des critères financiers, mais aussi sur un aspect

métier. Pour ne pas se retrouver avec une GMAO qui ne conviendrait pas à l’entreprise (perte

de temps et d’argent), nous choisissons la personnalisation et le développement. La

personnalisation évite les pertes de temps et d’argent, et favorise l’intégration. Et si dans le

future, une nouvelle fonctionnalité requise n’est pas présente, nous pouvons adapter le GMAO

facilement avec le développement, en évitant les coûts d’intégration et de changement. Le

développement spécifique évite le problème de formation spécifique du personnel, car

l’expérience utilisateur de l’ERP est unique.

Démarche adoptée

La démarche de développement des solutions ERP est distincte par rapport à la démarche de

développement d’un autre type de logiciel. Le développement d’un nouveau module est dirigé

par la stratégie, visions et objectif de l’entreprise. Les nouveaux besoins se manifestent.

Les fonctions stratégiques se transforment en processus, les processus se transforme en modules

ERP. La figure III-1 illustre une pyramide qui montre que la stratégie de l’entreprise dicte le

Module MDX

Nouveau Processus métier,

Exigences et nouveaux besoins, cartographie des processus

Vision et stratégie, Architecture de l’entreprise

Figure III-1 : Feuille de route de développement de module MDX

Rawdha Mabrouki

28

développement de nouveau module ERP. Cette figure est la feuille de route de développement

de ce nouveau module. Dans ce contexte, la gestion de maintenance est une fonction stratégique

qui doit être considérer dans l’architecture de l’entreprise. La démarche dicte qu’il faut analyser

l’existant en recueillant des données sur le processus humain, afin après de modéliser les

activités humaines à l’aide de la cartographie des processus. Puis nous allons déterminer la

portée du système en le décrivant avec le modèle de contexte. Enfin nous allons éliciter les

exigences, les raffiner…Après le développement, afin de valider le travail, nous pouvons

expérimenter le module dans un cas réel.

Cartographie des processus

Les principes de conception architecturale de MDX sont, la séparation des préoccupations, la

séparation des processus. Afin de définir les processus de maintenance, nous avons réalisé la

cartographie des processus.

La figure ci-dessus illustre la cartographie des processus lié à la gestion de maintenance. Nous

avons commencé par définir l’existant en réalisant une cartographie du fonctionnement et en

déterminant les processus clés. Ensuite, nous avons définis les cibles en obtenant une expression

complète des besoins, en déterminant des objectifs clairs et en dimensionnant correctement le

projet. Alors les processus clés de notre module ERP sont : la gestion de la maintenance

Figure III-2 : Cartographie des processus

Rawdha Mabrouki

29

externaliser, la gestion des demandes de travail, la gestion des ordres de travail, la planification

et ordonnancement des OT, l’exécution des OT et enfin le processus de rechange de pièces.

Communication avec autres processus

La GMAO communique avec d’autres processus métier autre que le processus de production.

Elle est en relation directe avec la direction technique, dans l’ordre de définir la politique de

mise en œuvre de grand projet. Et comme le montre la cartographie réalisée elle est en relation

direct avec les modules financiers, afin de contrôler les coûts suivant les budgets (William W.

Cato, 2002). Le module GMAO est en relation avec le système de direction RH afin de garantir

le guide du personnel interne en termes de compétences et missions. Notamment la maintenance

est en relation avec le magasin qui fournit les rechanges et consommables (William W. Cato,

2002). Enfin le service a également des relations externes avec ses fournisseurs et ses

prestataires.

III.3. Backlog Produit

Le Backlog produit est illustré dans l’annexe C. Le Product Backlog de notre projet comprend

les user stories, et tout autre artefact de gestion des exigences.

Spécification des exigences

Spécification des exigences permet de construire une meilleure compréhension du problème

(Bourque, 2014). L’élément essentiel dans la spécification des exigences est de préciser la

portée du projet. Ce qui implique de fournir une description du module en tant qu’une boite

noire, en spécifiant chaque livrable, son objectif et sa priorité (Bourque, 2014) (Siegel, 2000)

.Grâce à la priorisation nous pouvons assurer la délivrance des sous-modules les plus

importants. Cela minimise le risque de passer du temps à susciter des exigences de faible

importance (Bourque, 2014), (Siegel, 2000). Par exemple, nous ne devons pas délivrer la

fonctionnalité de gestion des contrats avant d’assurer la gestion des équipements et gestion des

ordres de travail. Car la gestion des contrats ne répond pas directement au problème. Dans cette

partie nous prenons le rôle d’un facilitateur. Le facilitateur utilise des techniques d’expression

de besoins fonctionnels et non fonctionnels, tel que le diagramme de contexte, le diagramme de

cas d’utilisation générale et les scénarios.

Identification des acteurs

L’identification des acteurs sert à délimiter le contour du système. Par définition : Un acteur

représente l’abstraction d’un rôle joué par des entités externes (utilisateur, dispositif matériel

ou autre système) qui interagissent directement avec le système (Bourque, 2014).

Rawdha Mabrouki

30

Chef service secteur : est responsable de l’élaboration de demande d’intervention.

Manager de maintenance : possède le privilège de plus haut niveau. Et il suivi les

indicateurs de performance de maintenance afin de prendre des décisions.

Responsable maintenance : gestionnaire charger de planifier, organiser et gérer les

demandes de travail reçus de la part d’un demandeur.

Technicien de maintenance : main d’ouvre qui indique l’avancement de son travail.

Chef équipe de maintenance : gère la main d’ouvre de maintenance.

Afin d’identifier les acteurs nous avons utilisé le diagramme de contexte. Le diagramme de

contexte statique permet de positionner le système dans son environnement selon un point de

vue matériel. Pour chaque type d’élément matériel extérieur au système, il est précisé les

cardinalités 14 (Bourque, 2014) .

La figure ci-dessus illustre le diagramme de contexte statique qui montre les relations des

différents acteurs avec le système.

Besoins fonctionnels

Après avoir identifié les acteurs nous allons identifier les besoins de ces acteurs. Par définition :

Les besoins fonctionnels expriment une action que doit effectuer le système en réponse à une

demande (sorties qui sont produites pour un ensemble donné d’entrées) (Siegel, 2000).En

particulier les problèmes métiers ne sont pas réalisé par des algorithmes mais par des cas

d’utilisation de traitement de données dit CRUD15 .Ils sont ainsi dits cas d’utilisation système,

orienté vers l’utilisateur. Notamment la cartographie des processus nous a permis d’identifier

14 Voir Glossaire 15Voir glossaire

Figure III-3 : Diagramme de contexte statique

Rawdha Mabrouki

31

les processus métier qui se traduisent dans ce stade à des cas d’utilisation métier. Donc nous

décrivons les différents besoins fonctionnels de notre module.

Gérer contrats : cas d’utilisation système (CRUD) permet de gérer la sous-traitance.

Gérer les ordres de travail : gestion des informations relatives aux ordres de travail,

et permet de gérer la maintenance corrective, préventive …

Contrôle des coûts : contrôler les coûts de main d’œuvre, de stocks, d’achat, de

location de matériel, suivi par périodique et rapports d’écart.

Gérer interventions : le technicien peut gérer les informations des interventions qu’il

a effectué, mettre à jour l’avancement de son travail. Le technicien peut seulement

mettre à jour ses propres interventions en cours. Donc les requêtes qu’il peut exécuter

sont RU (Retreive Update).

Consulter équipement : pour maintenir un équipement le technicien doit y avoir accès.

Gérer équipements : inventaire des équipements, localisation, historique des travaux,

gestion d’information dédiée par type d’équipements.

Affecter techniciens : gestion des absences personnels et affectation du travail selon

leurs compétences, activités métiers, planning de charge, prévisionnel et pointage des

heures travaillées sur intervention.

Suivre les KPI : indicateur de maintenance et tableau de bord pour le manager.

Imprimer équipements/OT par statuts : le responsable peut imprimer la liste des

équipements indisponibles etc. ou imprimer la liste des ordres de travail en retard etc.

Imprimer ordre de travail par période : le responsable de maintenance peut imprimer

les OT pour une période spécifique, pour la dernière semaine etc.

Demander travail : est un cas d’utilisation métier, où un responsable secteur peut

réclamer ou notifier pour un dysfonctionnement. Il doit dont indiquer l’équipement, le

département et la panne.

Planifier programme d’intervention : grâce à ce cas d’utilisation le responsable de

maintenance peut planifier un OT de n’importe quel type de maintenance.

Rawdha Mabrouki

32

Consulter programme d’intervention : cas d’utilisation métier permet au technicien

d’être notifier d’un nouveau travail avec son planning.

La figure ci-dessus illustre le diagramme de cas d’utilisation général de notre futur module.

Nous avons présenté les cas d’utilisation métier en bleu, les cas de reporting en rose et les

cas système en vers. Enfin l’acteur manager hérite toutes les fonctionnalités des autres

acteurs. Les stéréotypes RU et RUD sont des variations du pattern CRUD avec restriction

de création.

<<Include>>

<<extend>>

<<CRUD>>

Gérer les Contrats

<<RU>>

Gérer Intervention

<<CRUD>>

Gérer les Ordre de

Travail

<<CRUD>>

Gérer les équipements

commander pièces

Controler les

coûts

Affecter Technicien

Consulter Equipement

demander travail

Consulter programme

Technicein

Responsable maintenane

chef équipe

Responsable secteur

Manager de maintenance

planifier programme

<<Report>>

imprimer ordre de

travail par période

<<Report>>

imprimer ordre de

travail par status

<<Report>>

imprimer équipements

par status

<<RUD>>

Gérer les Demandes

Travail

Suivre KPI

Figure III-4 : Diagramme de cas d'utilisation générale

Rawdha Mabrouki

33

Besoins non fonctionnels

Les exigences non fonctionnelles et les contraintes de conception se rapportent spécifique à un

cas d’utilisation plutôt qu’au système dans sa totalité.

Planification des itérations

Cous avons remarqué que la plupart des entreprises utilisent quelques-unes des fonctionnalités

du GMAO. Le suivi des coûts, la gestion des contrats et d’autre fonctionnalités ne se pas

vraiment utilisés au jour le jour (R.Keith Mobley). Ils utilisent plus fréquemment le progiciel

pour gérer les demandes de travail et ordre de la maintenance (William W. Cato, 2002) et moins

fréquemment pour gérer les contrats. Le module de gestion des équipements est indispensable

dans un GMAO, puisque les équipements sont l’objet de maintenance. Donc nous avons

prioriser le module de gestion des équipements par rapport au module de gestion des ordres de

travail. Le tableau III-1 illustre la planification des itérations avec leurs statu risques et priorités.

Tableau III-1 : Aperçue de la planification des itérations

ID Sprint Cas d’utilisation Priorité Risque Statu

1 Gestion des

équipements

Gérer les équipements 1 Moyen Approuvé

Consulter équipement

2

Gestion des ordres

de Travail

Gérer les interventions

1 Élevé Approuvé

Gérer les techniciens

Gérer les demandes travail

Gérer les ordres de travail

Demander travail

3

Gestion des contrats

et planification

Gérer les contrats

1,5 Faible Brouillon

Contrôler coût

Planifier programme

Consulter programme

Flux de travail

4

Gestion des clés de

performance et le

reporting

Imprimer équipement par statu

2 Élevé Brouillon Imprimer OT par statu

Imprimer OT par période

III.4. Environnement technique et logiciel

Lors de ce stage, nous avons su utiliser un ensemble de technologies répondant à certain besoin

des histoires techniques. Dans cette partie nous allons présenter l’environnement Dynamics AX

Rawdha Mabrouki

34

dans lequel les futurs sous-modules seront développés. Nous présentons ensuite

l’environnement intégré de développement. Enfin nous allons présenter le principe de

développement dirigé par modèle de MDX.

Architecture logicielle de Dynamics Ax

La solution Dynamics AX est fournie sur une plate-forme de technologie Microsoft.

La figure III-5 illustre l’architecture logique de la solution Microsoft Dynamics Ax. C’est une

architecture trois tiers. Elle est divisée en trois niveaux ou couches : couche accès aux données,

couche métier, couche présentation (Team, 2012).

Couche accès aux données

La couche accès aux données est centralisée et géré par l’SGBD SQL Server 2014 (Team,

2012). Elle permet de stocker et gérer les données de différents types. Bases de données SQL

Server SQL Server est le cœur BI de Microsoft (Withee, 2010). Il est constitué d’un moteur de

base de de donnée standard, SSRS, SSIS et de SSAS (Mohammed, 2014). Le moteur de base

de données gère les bases de données relationnel16 et multidimensionnelle17. Il héberge le

contenu SharePoint Server et le Model Store qui est la base de données qui stocke les

métadonnées18 et codes des applications (Birch, 2013). Le moteur de base de données permet

de manipuler les données de type Master Data, données transactionnels et organisationnel etc.

C’est la version OLTP de Microsoft (Mohammed, 2014). SSAS est la version OLAP de

Microsoft (Withee, 2010). Elle stocke une grande masse de données dans des cubes pour

effectuer les analyses en temps réel (Team, 2012). SSRS permet de créer des états (reports) en

16 Voir glossaire 17 Voir glossaire 18 Voir glossaire

Figure III-5 : Architecture trois tiers de Dynamics Ax (Team, 2012)

Rawdha Mabrouki

35

se basant sur des requêtes, en transformant les enregistrements en une information donnant une

base de connaissance qui permet de prendre des décisions (Team, 2012). Il crée les documents

relatifs à un processus tel qu’une demande de travail ou un ordre de travail. Enfin SSIS permet

de collecter les données de différents source en les transformant en un seul format et en les

chargeant dans la base de données tous en utilisant le processus ETL (Withee, 2010).

Finalement Ax supporte l’héritage des tables et tous autres caractéristiques orienté-objet. Ce

qui augmente la commodité de conception de schéma de la base de données de notre solution.

Couche présentation

La couche présentation est la couche responsable de la disposition de données stockées dans

SQL Server. Elle est constituée du Client applications. Ce sont le client riche, le portail

entreprise EP, .Net business connector, et le client d’intégration avec autres applications

(Mohammed, 2014). La figure III-6 illustre le Client applications et ses sous ensemble. Le client

business connector est une interface conçus pour donner à d’autres applications externe l’accès

au logique métier de Dynamics Ax. Le portail d’entreprise est basé sur la technologie Microsoft

SharePoint avec l’authentification Windows Live, ainsi que les rendus des pages son basé sur

l’interface de client riche (Birch, 2013).

III.4.3.1 Client riche

Le client riche est une application donnant des interfaces utilisateur adaptées au rôle. Elle est

appelée aussi client Workspace. C’est une application Windows basé sur les formulaires qui

permet aux utilisateurs d’interagir avec les données stockées sur le serveur de manière

transparente. Le point de départ de cette application est le Rôle Center (cf. Figure III-6) où

chaque utilisateur à sa propre Area Page (cf. Figure III-7). Après, si l’utilisateur choisi de

consulter la liste des clients par exemple, un formulaire de type ListPage s’ouvre. Après si

l’utilisateur veut consulter un client, un formulaire type DetailsFormMaster ou

DetailsFormTransaction s’ouvre. Dynamics Ax offre des Patterns d’interface :

ListPage : première page d’un module,

DetailsFormMaster : permet de consulter et modifier les données de type master,

DetailsFormTransaction :permet de consulter et modifier les données transactionnelles,

SimpleListDetails : présente les données de références et donnée de configuration,

SimpleList : permet des recherches basiques,

TableOfContents : entré au module de configuration,

Dialogue et DropDialog : interaction rapide avec l’utilisateur.

Rawdha Mabrouki

36

III.4.3.2 Outils d’analyse et pilotage des activités

Les outils d’analyse et pilotage de l’activité de l’entreprise offerte par Dynamics Ax sont les

tableaux croisés dynamiques, le gestionnaire graphique des cubes les KPI, des formules de

calcul et les tableaux de bord. (Mohammed, 2014). L’utilisateur peut bénéficier d’un accès aux

files d’attente de tâches visuelles, aux processus métier et rapports, aux notifications, (Birch,

2013) et autres informations stratégiques présentés sur le Cues. La suite d’outils de BI de

Microsoft Dynamics Ax offre des outils de reporting au service de pilotage (Team, 2012). Les

interfaces par défaut dit rôle center et le reporting Ad-hoc sont l’une des fonctionnalités les plus

utilisées. Les rôles center sont le premier niveau de tableau de bord (Team, 2012). Ils permettent

d’avoir un aperçu des informations dont l’utilisateur connecté a besoin pour son activité. Ainsi

que les éléments de cette page d’accueil sont mis à jour en temps réel à partir des données

saisies et calculés. Les états peuvent être publiés (affichés) sur le Rôle Center dans une Web

part. Après l’utilisateur est dirigé vers d’autre page la page de zone ou Area Page.

III.4.3.3 Page de secteur

La page de secteur (Area Page) est spécifique à chaque rôle (cf. Figure III-7). Elle est constituée

de plusieurs menus appelant aux autres pages. Les menus sont :

Courant : (common) contient les éléments les plus couramment utilisés de menu pour

un module d’application. La plupart des éléments de menu de ce groupe sont conçus

pour trouver rapidement un enregistrement ou un groupe d’enregistrements, puis

effectuer une action sur ces enregistrements.

Journaux : (journals) sont utilisés pour l’affichage des données transactionnelles. Les

détails des journaux sont la transaction qui a eu lieu et à qu’el comptes a été affecté. Ce

groupe de menu fournis un accès à des formulaires avec des revues.

États : sont conçus pour afficher les données dans un format de rapport imprimable.

Figure III-6 : Rôle Center (Keith Dunkinson, 2013)

Rawdha Mabrouki

37

Paramétrage : (setup) contient des éléments de menu qui maintiennent la

configuration générale de caractéristiques liées au module sélectionné

Périodique : (Periodics) contient des éléments de menu pour les formulaires qui sont

utilisés régulièrement. Ils sont souvent utilisés pour les mises à jour à un ensemble

d’enregistrements (Mohammed, 2014).

Recherches : (Inquiries) sont conçus pour accès en lecture seule à l’information. Ils

permettent la recherche et l’analyse des données sans besoin de générer un rapport. Ce

groupe de menu offre accès aux formulaires utilisés pour l’enquête (Mohammed, 2014).

La figure ci-dessus illustre la page de secteur du module immobilisation. La page de secteur est

la page qui permet aux utilisateurs d’accéder aux autres formulaires et ListPage d’un module.

Donc chaque module a sa propre page de secteur.

Couche métier

L’AOS est le serveur d’application de MS Dynamics Ax. C’est là où le logique métier

s’exécute. L’AOS permet d’exécuter des services d’application MorphX, précisément le code

X++qui fournit le logique métier des applications. Les relations entre les tables de la base de

données sont gérées coté AOS (Team, 2012).

Environnement de développement intégré

MorphyX et Visual studio sont l’ensemble d’environnement de développement qui seront

nécessaires afin d’implémenter notre module GMAO (Team, 2012).

III.4.5.1 MorphyX

MorphyX est dit aussi Developper workspace, permet de développer des classes et des requêtes

en utilisant un outil de modélisation l’AOT (Team, 2012). Ainsi qu’il permet de réaliser des

Figure III-7 : Page de Secteur

Rawdha Mabrouki

38

personnalisations faites graphiquement (Drag and drop) pour concevoir des tables, des requêtes,

des formulaires, des menus et des rapports.

III.4.5.2 Langage de programmation X++

Le langage utilisé pour développer des applications Dynamics AX se nomme X++. Il s’agit

d’un langage respectant les principes de la programmation orientée objet tels que

l’encapsulation, l’héritage, les classes, les objets, les méthodes et les propriétés. La syntaxe du

langage X++ est proche de celle du langage C# ou java. Le point fort de X++ c’est qu’il inclut

des commandes SQL intégrées, et qu’il permet de changer le contrôle de comportement des

interfaces utilisateurs, formulaires et menus.

III.4.5.3 Visual Studio IDE

L’environnement de développement Visual Studio est utilisé pour développer des plug-ins pour

Microsoft .NET et des extensions de Microsoft Dynamics AX clients, et des web services. Il

permet ainsi de développer des rapports SSRS (Team, 2012). Cet environnement de

développement permet aussi accéder aux services de serveur d’applications AOS (Team, 2012).

Workflow de Dynamics Ax

Le workflow permet de rationnaliser, coordonner et contrôler les activités du processus métier.

Pour chaque module Ax il existe une catégorie de workflow. Ainsi pour créer notre nouveau

module nous allons lui associer une nouvelle catégorie de workflow.

Ils exitent deux types de workflows : workflow humain qui nécéssite l’intéraction et des

approbations des utilisateurs et les workflows système qui sont non-interactives. Les workflows

humains sont de deux types : Structurés et non-structurés. Et les workflows systémes automatise

totalement un processus. Ils s’étend sur plusieurs systèmes, tel que le transfert d’une commande

d’un système à un autre. Danc ce contexte nous allons utiliser les les workflows humain afin

d’automatiser les activités de maintenance, car nous avons un besoin intensif d’approbation.

Principes de conception architecturale du Dynamics Ax

Dynamics Ax est conçu suivant une architecture basée sur les modèle MDLA. Ce concept

architectural permet d’exécuter plus facilement le développement (Mohammed, 2014). Le

système étant défini à l’aide de modèles, les besoins spécifiques peuvent être pris en charge de

manière déclarative, sans écrire trop de code (Mohammed, 2014).

Rawdha Mabrouki

39

III.4.7.1 Modèle en couches de Dynamics Ax

Dans MDX, un modèle est un regroupement logique d’éléments dans une couche. Les modèles

sont utiles dans plusieurs solutions ou projets ISV qui doivent fonctionner ensemble. Cette

architecture permet à beaucoup de solutions de coexister dans chaque couche (Team, 2012).

Nous avons utilisé la couche SYS en tant qu’existant. Et nous allons développer le reste de

notre module sur la couche ISV sur un modèle que nous avons ajouté et nommé GMAO.

III.4.7.2 Couches de Dynamics Ax

Le tableau III-2 illustre chaque couche dans Microsoft Dynamics Ax. Les histoires utilisateurs

de chaque future Sprint seront consacré à développer des Rôle Center, ListPage, Page de

Secteur, Workflow ... sur chaque notre model GMAO.

Tableau III-2 : Modèle de couches de Dynamics Ax (Birch, 2013)

III.5. Conclusion

Ce chapitre a constitué la première phase de rédaction du Product Backlog reprenant tous les

besoins et en cherchant les fonctionnalités inexistantes dans l’ERP MDX, utiles pour une

GMAO et celles qui nécessite une extension. Afin de résoudre la problématique nous avons

préparé les besoins fonctionnels de la solution, les rôles et utilisateurs, ainsi que le diagramme

des cas d’utilisation général. Enfin nous avons détaillé l’architecture technique de notre projet.

Dans les chapitres qui suivent, nous allons présenter les Sprints constituants notre projet.

Couc

he Description

USR User layer : La couche d’utilisateur pour les modifications réalisé par l’utilisateur, tels que les

rapports.

CUS Customer layer : La couche de client permet d’apporter des modifications qui sont spécifiques à

une entreprise.

VAR Value Reseller layer : Revendeurs à valeur ajoutée (VAR) peut apporter des modifications ou de

nouveaux développements de la couche VAR comme spécifié par les clients ou comme une

stratégie de création d’une solution spécifique de l’industrie.

ISV Independent software vendor layer : Quand un fournisseur indépendant de logiciels (ISV) crée

sa propre solution, les modifications sont enregistrées dans la couche ISV.

SLN Solution layer : La couche de solution est utilisée par les distributeurs à mettre en œuvre les

solutions des partenaires verticaux.

FPK Feature Pack layer : La couche FPK est une couche de brassage de l’objet de l’application

réservée par Microsoft pour les mises à jour.

GLS Globalisation layer : Lorsque l’application est modifiée en fonction de besoins juridiques propres

à chaque pays ou région, ces modifications sont enregistrées dans la couche GLS.

SYS System layer : L’application standard est mise en œuvre au niveau le plus bas, dans la couche

SYS. Les objets d’application dans la couche SYS ne peuvent jamais être supprimés.

Rawdha Mabrouki

40

Chapitre IV. Élaboration du Sprint 1

IV.1. Introduction

Après avoir défini la branche technique du projet, il ne nous reste que de nous diriger vers les

Sprints qui décrivent les principaux objectifs et les fonctionnalités de notre futur module. Cette

partie sera concernée à l’étude et la réalisation du Sprint 1, la gestion des équipements.

IV.2. Sprint Backlog

Notre Sprint Backlog est le tableau que nous tirons du Backlog Product qui formalise le

calendrier pour le sprint relatif à la gestion des équipements.

Ce module doit permettre de gérer les équipements d’une unité de production, sur différents

axes. Sur l’axe technique et l’arborescence des équipements et leur description et sur l’axe de,

ainsi que sur l’axe financier et disponibilité et maintenance. Le module immobilisation n’offre

pas l’axe technique, de disponibilité et l’axe de suivi de maintenance. Nous avons donc exploré

l’existant afin spécifier les exigences relatives à ce module. Nous avons collecté des

informations sur ce module afin de définir le squelette de la base de données existante.

Étude du module immobilisation

Alors notre objectif consiste à trouver les fonctionnalités qui manquent ce module pour fournir

la gestion des équipements de production, avec toutes les spécifications de maintenance. La

figure ci-dessus illustre un aperçu sur le module immobilisation.

Figure IV-1 : Aperçu du module immobilisation [W9]

Rawdha Mabrouki

41

Ce module fourni plusieurs autres sous-fonctions nécessaires pour gérer les actifs tel que la

gestion de la dépréciation, la réévaluation et le transfert des immobilisations vers un

regroupement de faible valeur.

Cas d’utilisation gestion des équipements

Dans cette partie nous allons détailler le cas d’utilisation système gérer les équipements. Le

raffinement du cas d’utilisation gérer les équipements produit plusieurs autres cas d’utilisation

comme extension du module immobilisation. Le chef d’équipe de secteur de production peut

donc lister les équipements disponibles, et indisponibles. La figure ci-dessous illustre le

diagramme de cas d’utilisation gérer les équipements.

IV.3. Conception générale

Pour de réaliser la conception générale nous avons détaillé le cas d’utilisation ‘consulter détail

d’un équipement’ et le cas d’utilisation ajouter nouvel équipement. Après nous avons précisé

les autres éventuels cas, et états de l’équipement afin de décrire la structure statique du sous-

module.

Raffinement du cas d’utilisation Ajouter équipement

Afin de décrire le cas ajouter équipement nous avons utilisé la description textuelle et le

diagramme de séquence. Les scénarios sont rassemblés à partir des User Stories.

Figure IV-2 : Diagramme de cas d’utilisation ‘Gérer les équipements

<<Extend>>

<<Extend>>

<<Extend>>

<<Extend>>

<<Extend>>

<<Extend>>

<<Extend>>

<<Extend>>

<<CRUD >>

gérer les équipements

Consulter la liste des équipements

chercher un équipement

filter la liste des équipements

Modifier un équipement

Supprimer un équipements

Ajouter nouveau équipement

Consulter la liste des équipements Disponible

Consulter la liste des équipements non

Disponible

Consulter la liste de tous les équipements

Chef d'équipe du Secteur

Déplacer Equipement

Copier équipement

Consulter détails d'un équipement

Rawdha Mabrouki

42

Identification cas n°1 : Ajouter équipement

Nom : Ajouter équipement

Acteur principal : Responsable secteur

Objectif : l’ors de l’achat d’un équipement le responsable secteur ajoute les informations et

coordonnés afin de suivre son état.

Précondition : l’utilisateur s’authentifie en tant que responsable secteur et l’emplacement de

nouvel équipement existe dans la table Location si non l’utilisateur doit préciser un nouvel

emplacement.

Dialogues

Scénario nominal

1. Le responsable ajoute une nouvelle immobilisation.

2. Le système affiche le formulaire d’ajout.

3. Le responsable spécifie le groupe de l’immobilisation.

4. Le système crée un équipement avec un identifiant Mach-XXX et un statu acquis.

5. Le responsable saisi tous les coordonnés obligatoires.

6. Le système vérifie les champs obligatoires.

7. Le responsable secteur spécifie ou moins une pièce détachée dans la structure de

l’équipement. Il ajoute les outils, accessoires et type du compteur adéquat.

8. Le système enregistre et affiche les informations détaillées du nouvel équipement.

9. Le responsable change le statu de l’équipement de acquis à en instance ou à en usage.

10. Le système enregistre le statu modifié.

Scénario optionnel

11. Le responsable peut attacher un document, une fiche ou une photo de l’équipement.

12. Le système enregistre le document.

Scénario alternatif

6.a des champs obligatoires sont pas saisies.

6.b le responsable reprend le scénario 5.

Exception : enregistrement pas réussi.

Fin et Post-condition : un nouvel équipement a été enregistré dans son emplacement avec ses

pièces détaché.

Compléments

Ergonomie : l’enregistrement de l’équipement doit être sur une seule page ainsi que l’utilisateur

doit pouvoir visualiser l’ensemble des pièces, compteurs et accessoire sur la page d’ajout et

consultation de l’équipement.

Rawdha Mabrouki

43

La figure ci-dessus illustre le diagramme de séquence de scénario nominale de cas d’utilisation

ajouter équipement. Le stéréotype DétailsFormMaster, ListPage et SimpleListDetails décrivent

les patterns d’interface utilisateur de Dynamics Ax, ainsi que les flèches émises de l’acteur vers

les interfaces sont des évènements portant des informations. Les flèches entre interfaces ou

entité décrivent les évènements tels que ‘update’ et ‘create’. Les flèches pointées représentent

la réponse et changement des interfaces utilisateurs.

Figure IV-3 : Diagramme de séquence de scénario nominale d’Ajout équipement

Rawdha Mabrouki

44

Raffinement du cas d’utilisation ‘Consulter détail équipement’

Lors de la consultation d’un équipement spécifique, l’utilisateur peut planifier un ordre de

travail, imprimer fiches, ainsi qu’il peut élaborer une nouvelle demande de travail.

La figure ci-dessus illustre le diagramme des cas d’utilisation consulter détail équipement. Or,

les cas d’utilisation qui l’étendent sont élaborer demande de travail et ajouter préventif et suivre

historique des pannes ces cas ne seront pas développés au niveau de ce Sprint, car leur contexte

appartient au Sprint suivant gestion des ordres de travail. Le cas d’utilisation imprimer fiche de

l’équipement sera détaillé au niveau du Sprint 3.

Raffinement de cas d’utilisation Élaborer demande de Travail

Lorsque le responsable secteur est intéressée par une réclamation, à partir du module gestion

des équipements et à tout moment il peut créer une demande. Alors afin de décrire le cas

d’utilisation élaborer demande travail nous avons utilisé la description textuelle qui nous aidera

à développer un diagramme de séquence.

Identification cas n°2 : élaborer demande de travail

Nom : élaborer demande de travail.

Acteur principal : le responsable secteur.

Objectif : le responsable de secteur peut réclamer une observation à partir de la List page des

équipements.

Précondition : l’utilisateur s’authentifie en tant que responsable de secteur, la liste des

équipements se charge.

Dialogues

Scénario nominal

1. Le responsable sélectionne un équipement ou un groupe d’équipement et il clique sur le

bouton notifier observation.

<<extend>>

<<extend>>

<<extend>>

<<extend>>

<<extend>>chef équipe production

Consulter détail équipement

Ajouter préventif

Imprimer fiche de l 'équipement

élaborer demande de travail

controler cout de maintenance

suivre historique des pannes

Figure IV-4 : Diagramme de cas d’utilisation consulter détail

Rawdha Mabrouki

45

2. Le système charge la séquence de scénario d’ajout de demande de travail.

3. Le responsable change l’état de l’équipement d’en service à en panne.

Scénario alternatif

2.a l’un des équipements sélectionner est déjà en état indisponible. Le système affiche

une erreur et l’utilisateur reprend le scénario 1.

Exception : enregistrement pas réussi si l’utilisateur ne confirme pas le formulaire et l’opération

entière est annulée

Fin et Post-condition : le statu de l’équipement est mis à jour automatiquement à indisponible.

Et une nouvelle notification doit être envoyée au responsable maintenance.

Compléments

Convivialité : les boutons notifier observation et changer statu doivent être visibles sur la page

de gestion des équipements.

La figure ci-dessus est le diagramme de séquence de scénario nominale du cas élaborer

demande de travail. Alors la référence sequence diagram_demander travail de maintenance va

être traitée au niveau du Sprint 2, gestion des ordres de travail.

Diagramme d’état transition de l’objet métier équipement

Un équipement peut subir plusieurs changements du cycle de vie. Selon la fonction, l’âge et des

décisions d’achat et de vente l’équipement passe d’un état à un autre. Il passe par l’état acquis

juste après son acquisition. Il peut être en instance ou en usage. S’il est affecté à un secteur

opérationnel. Puis il passe à l’état endommagé s’il a dépassé un certain âge ou s’il est détérioré.

Ou il est en panne, dans ce cas il sera maintenue et corrigé. L’état réformé désigne un

Figure IV-5 : Diagramme de séquence élaborer demande Travail

Rawdha Mabrouki

46

équipement qui a été maintenu après une maintenance corrective. L’équipement peut passer à

l’état détruit ou vendu après une décision de vente.

La figure ci-dessus illustre le diagramme d’état transition de l’objet équipement. Les états en

bleu, présentés sur le diagramme sont les états existants dans le module Immobilisation.

IV.4. Conception détaillée

La conception détaillée nous a permis d’explorer en plus de détail le module immobilisation.

Alors, le diagramme classe du module est constitué des tables : AssetTable, AssetBookTable.

Diagramme de classe

Nous avons défini le diagramme de classe avec une précision de nouvelles classes. Nous avons

ainsi ajouté les caractéristiques spécifiques d’un équipement au niveau de la classe AssetTable.

Ainsi que nous avons ajouté les classes :

La classe GMAOPieceDetach présente la liste de pièces détachées d’un équipement.

Or un équipement est composé de plusieurs pièces qui peuvent être maintenues.

La classe Compteur décrit les compteurs d’un équipement. Les enregistrements des

compteurs sont utilisés dans la planification de maintenance préventive systématique.

La classe GmaoOutilcollecte les données des outils de maintenance d’un équipement.

Casse GmaoAssetAccessoire instruit les valeurs des caractéristiques correspondantes à

chaque accessoire des équipements.

/ démarrer ordre de travail

/ test d'inspection validé

/ Correction

/ destruction

Scrapped

Sold

/ Installation sur pour une unité de

production

/ Valider maintenance Préventive

/ Décision de vente

/ Création par défaut

/ AchatAqui

en usage

en panne

en maintenance

réformé

ferail le

en instance

Vendu

endommagé

Pas encore acquis

Suspendu

transferred to low Pool

/ panne

/ agé ou détérioration

Figure IV-6 : Diagramme d’état transition de l’objet équipement

Rawdha Mabrouki

47

La figure ci-dessus illustre le diagramme de classe de gestion des équipements. Alors notre

diagramme décrit les relations entre différentes entités. En effet la classe AssetTable est la classe

principale du sous-module. Et nous avons un grand choix de conception, d’ajouter les champs

décrivant les caractéristiques d’un équipement à la classe ou de créer une nouvelle classe

caractéristique lié à la classe AssetTable. Nous avons choisi donc d’ajouter directement les

champs. La suppression de l’instance de la classe AssetTable engendre forcément la suppression

de la classe compteur. Et chaque instance de AssetTable peut avoir plusieurs compteurs de type

différents.

Schéma relationnel de la base de données

Nous avons transformé le modèle orienté objet en modèle physique de données. Notamment le

modèle physique de données permet de valider le schéma de la base de données en spécifiant

les clés étrangères à partir des cardinalités et relations entre classes. Le passage de diagramme

de classe vers le schéma de la base de données a généré une nouvelle table, la table

GmaoOutillage. Vue que la relation entre la table AssetTable et GmaoOutil est une agrégation

et la cardinalité est zéro à plusieurs. Nous remarquons alors que c’est une relation de

Figure IV-7 : Diagramme de classes de Sprint 1

AssetTable

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

AssetId

AssetType

...

PressionEpreuve

Puissance

Status

Volume

Cylindrée

Vitesse

Huile

AutreCaractérisrique

ModeRefroidissement

TensionEnAmpère

TensionCourtCircuitEnPourcent

CriticitéEquip

PièceManquante

disponible

Surface

Hauteur

Poids

ImportanceLigne

PiècesDétaché

: int

: int

: int

: double

: double

: int

: double

: boolean

: double

: boolean

: String

: String

: double

: double

: String

: String

: int

: double

: double

: double

: int

: String

GMAOPièceDétaché

+

+

+

+

+

+

NuméroPièce

prix unitaire

DésignationPièce

NuméroSériePièce

DescriptionPièce

FournisseurPièce

: String

: double

: String

: String

: String

: String

GmaoAssetAccessoire

+

+

+

+

+

+

+

+

+

+

NuméroAcces

Caractéristiques

NomAccesoire

DateAchatAccesoire

FabricantAccesoire

MarqueAccesoire

DescriptionAccesoire

PrixAchatAccesoire

NumeroSerieAccesoire

ModeleAccesoire

: String

: String

: String

: Date

: String

: String

: String

: double

: String

: String

Compteur

+

+

+

+

+

+

NumCompteur

TotalCompteur

DateEnregistrement

ItemProduit

jourProduction

HeureProduction

: String

: double

: Date

: String

: double

: double

GmaoOutil

+

+

NuméroOutil lage

DescriptionOutil

: int

: int

1..1

1..*

1..1

0..*

1..1

0..*

0..*

0..*

Rawdha Mabrouki

48

composition faible (ou partagée). En d’autres termes, la suppression de l’agrégat (une instance

de AssetTable) n’entraîne pas nécessairement celle de son composant (GmaoOutil) qui peut être

en association avec une autre instance de l’agrégat ou avec une entité d’une autre classe.

Notamment la suppression des instances de l’une des deux GmaoOutil ou AssetTable entraîne

forcément la suppression de l’entité GmaoOutillage.

La figure ci-dessus illustre la structure de la base de données du Sprint1. Enfin nous avons

nommé les tables avec un préfix Gmao afin de distinguer les tables relatives à notre module

GMAO par rapport aux autres groups des tables existantes sur la couche SYS du Dynamics Ax.

IV.5. Réalisation

Dans cette phase, les concepts et les objectifs sont traduits en actions concrètes, et en

conséquence, il est peut-être l’une des phases les plus difficiles du projet. Nous décrivons

brièvement la phase de mise en œuvre de module de gestion des équipements en présentant les

interfaces utilisateurs.

AssetTable

AssetId

AssetType

...

PressionEpreuve

Puissance

Status

Volume

Cylindrée

Vitesse

Huile

AutreCaractérisrique

ModeRefroidissement

TensionEnAmpère

TensionCourtCircuitEnPourcent

CriticitéEquip

PièceManquante

disponible

Surface

Hauteur

Poids

ImportanceLigne

PiècesDétaché

int

int

int

numeric

numeric

int

numeric

bit

numeric

bit

varchar(254)

varchar(254)

numeric

numeric

varchar(254)

varchar(254)

int

numeric

numeric

numeric

int

varchar(254)

<pk>

GMAOPieceDetache

AssetId

NuméroPièce

prix unitaire

DésignationPièce

NuméroSériePièce

DescriptionPièce

FournisseurPièce

int

varchar(254)

numeric

varchar(254)

varchar(254)

varchar(254)

varchar(254)

<pk,fk>

<pk>

GmaoAssetAccessoire

NuméroAcces

AssetId

Caractéristiques

NomAccesoire

DateAchatAccesoire

FabricantAccesoire

MarqueAccesoire

DescriptionAccesoire

PrixAchatAccesoire

NumeroSerieAccesoire

ModeleAccesoire

varchar(254)

int

varchar(254)

varchar(254)

datetime

varchar(254)

varchar(254)

varchar(254)

numeric

varchar(254)

varchar(254)

<pk>

<fk>

GmaoCompteur

NumCompteur

AssetId

TotalCompteur

DateEnregistrement

ItemProduit

jourProduction

HeureProduction

varchar(254)

int

numeric

datetime

varchar(254)

numeric

numeric

<pk>

<fk>

GmaoOutil

NuméroOutil

DescriptionOutil

NomOutil

int

int

String

<pk> GmaoOutil lage

AssetId

NuméroOutil

int

int

<pk,fk1>

<pk,fk2>

Figure IV-8 : Schéma relationnel de la base de données de Sprint 1

Rawdha Mabrouki

49

La figure ci-dessus propose un modèle ergonomique, avec l’utilisation des grilles pour afficher

la liste des compteurs, accessoires, outils et pièces détachés. Au niveau de chaque grille nous

travons un panel d’action qui permet d’effectuer l’ajout ou la suppression d’un accessoire outil

ou compteur. Le bouton pièce détaché permet de gérer les pièces de l’équipement.

La figure ci-dessus illustre le formulaire d’ajout d’un compteur pour l’équipement consulté.

L’utilisateur peut ajouter toute une liste de compteur pour un seul équipement. Il saisit le

nombre d’heure de production et le nombre d’item produit.

Figure IV-10 : Interface d’ajout d’un équipement

Figure IV-9 : Formulaire d’ajout d’un compteur

Rawdha Mabrouki

50

La figure ci-dessus illustre le formulaire d’ajout d’un outil. L’utilisateur peut ajouter le nom et

prix d’un outil afin qu’il soit pris en compte lors du calcul des coûts de maintenance. Nous

avons choisi d’utiliser le pattern SimpleList afin de facilité la gestion des outils. Puis

l’utilisateur peut choisir la liste d’outillage pour l’équipement.

La figure ci-dessus illustre le formulaire d’ajout d’une pièce détaché pour un équipement

particulier. Nous avons choisi d’utiliser le pattern de type SimpleListDetails afin de garantir la

visualisation de la liste des pièces et leur mise ajour dans une seule page. L’utilisateur peut

ajouter le prix d’achat de la pièce, le fournisseur, le modèle et d’autres informations de la pièce.

Ainsi que deux boutons : nouveau et supprimer permette de gérer les pièces.

Dans la page de consultation d’un équipement, dans la grille de gestion des accessoires,

l’utilisateur peut cliquer sur le bouton nouveau ou supprimer afin de gérer les accessoires dans

cette page. Ainsi que l’utilisateur peut cliquer sur le bouton accessoire qui l’invite à gérer les

accessoires de manière plus propre sur la page de type SimpleListDetails.

Figure IV-11 : Formulaire de gestion d’une pièce

Figure IV-12 : Interface de gestion d'outil de maintenance

Rawdha Mabrouki

51

La figure ci-dessus illustre le formulaire de gestion d’un accessoire d’un équipement

La figure ci-dessus illustre la List page des équipements. Au niveau de cette interface nous

avons ajouté les attributs Disponibilité et Statu. D’où l’utilisateur peut trier les équipements par

statu, ou lister les équipements non-disponibles.

Si l’utilisateur double clic sur l’un des équipements, il est dirigé vers la page de consultation de

type Master détails. L’utilisateur clique sur la menue maintenance. En termes de

personnalisation nous avons ajouté une nouvelle liste de boutons : Ajouter demande,

maintenance préventive, coût de maintenance, fiche de l’équipement et historique des pannes.

Figure IV-13 : Interface List Page des équipements

Figure IV-14 : Interface de gestion des accessoires

Rawdha Mabrouki

52

La figure ci-dessus illustre l’interface master détails d’un équipement de production. Le bouton

ajouter demande de trvail permet d’afficher un formulaire de type dropDialog qui contient les

champs obligatoires d’ajout d’une demande. L’utilisateur saisie le mode de défaillance,

l’observation et la note sur la demande. La date de l’arrêt est initialisée à la date du jour, mais

l’utilisateur peut modifier cette date en spécifiant ainsi l’heure de l’arrêt.

La figure ci-dessous illustre l’interface de planification d’un préventif pour l’équipement

sélectionner. Nous avons choisi l’interface le plus rapide de type DropDialog, il contient alors

les champs : Date début et charge en heure ainsi qu’un champ de choix de diagramme de Gantt.

Figure IV-16 : Interface Master Détails d’un équipement et DropDialog demander travail

Figure IV-15 : Interface de planification d'un préventif

Rawdha Mabrouki

53

Enfin si l’utilisateur clique sur le bouton historique des pannes le système charge l’interface de

consultation de l’historique des pannes en affichant la pièce en panne, l’anomalie et toutes

informations relatives à la maintenance de la pièce en panne.

La figure ci-dessus illustre l’interface de consultation de l’historique des pannes pour

l’équipement.

IV.6. Conclusion

Au cours de ce chapitre nous tenons suivre le Sprint Backlog réalisé. Pour ce faire nous avons

passé par la phase de conception en finissant par une réalisation des User Story. Les interfaces

demande de travail, planification du préventive et historique des pannes sont réellement réaliser

au niveau du Sprint suivant. Dans le chapitre suivant nous allons entamer le Sprint 2.

Figure IV-17 : Interface de consultation de l'historique des pannes

Rawdha Mabrouki

54

Chapitre V. Élaboration du Sprint2 et 3

V.1. Introduction

Après avoir validé le Sprint 1 de personnalisation de module de gestion des équipements, nous

allons nous diriger vers les sprints 2 qui décrit les principaux objectifs et les fonctionnalités du

sous-module de gestion des ordres de travail et gestion de contrat. Cette partie sera concernée

à l’étude et la réalisation de ce Sprint, de l’analyse vers la conception détaillée.

V.2. Sprint Backlog

Le Sprint Backlog de gestion des ordres de travail est le tableau que nous tirons du Backlog

Product qui formalise le calendrier pour ce sprint. D’après le Sprint Backlog nous avons défini

certaines user stories que nous allons détailler dans la conception générale.

V.3. Conception générale

Afin de bien encadrer l’objectif et la sous-fonction demandée par le module de gestion des OT,

nous avons recours au diagramme d’activité. En effet d’après la cartographie de processus que

nous avons établi, nous avons à considérer les processus : Demander travail, gestion des OT,

exécution des OT, Commander pièce de rechange.

Diagrammes activité

Les diagrammes d’activité (cf. Figure VI-3) ((cf. Figure VI-4) nous a permis d’identifier les états

des objets métiers (OT et DT). Le diagramme d’état transition de l’objet OT (cf. Figure VI-1) et

le diagramme d’état transition de l’objet DT (cf. Figure VI-2) décrivent les statuts des objets

métiers. Ainsi que le diagramme d’activité de gestion d’OT nous permis d’identifier les activités

du module en spécifiant avec plus de détails les différents acteurs externes. L’acteur externe

dans ce cas est la direction financière. Alors les activités sont : planifier MP, consulter DT,

générer OT, planifier programme, gérer intervention, vérifier stock, demander

réapprovisionnement, réserver pièce, enregistrer consommation, effectuer

réapprovisionnement, clôturer OT etc.

Rawdha Mabrouki

55

L’objet métier ordre de travail peut ainsi transiter l’un état à un autre. À l’ajout d’un OT, l’objet

prend le statut créé.

Le responsable de maintenance peut changer le statut vers externalisé si les activités de

maintenance sont prises par un sous-traitant. Cependant le responsable peut planifier l’OT, donc

elle prend le statut planifié. Dans le cas des besoins que ce soit de main d’ouvre ou pièce de

rechange, l’OT prend le statut en attente. Puis si l’ordre reste dans statu en attente une période

dépassant une période prédéfinit, l’OT devient alors bloqué.

Une demande de travail peut transiter entre différents états. Si une faille est trouvée donc le

responsable de maintenance accepte la demande et s’il a généré un ordre de travail alors la

demande prend automatiquement le statut ‘engagé. Puis si aucune faille n’a été trouvée le

responsable peut refuser la demande. Le responsable secteur peut annuler une demande. Enfin

elle prendra le statut historié.

Figure V-1 : Diagramme état-transition de l’objet OT

/ planifier OT / dépasser date

/ Convertir DT en OT

/ Décision d'externalisationCréé

planifié en retard

Clôturé

en Progression

Historisé

externalisé

En attente

/ indisponibil ité pièce rechange

/ Disponibil ité pièce rechange/ Disponibil ité pièce rechange / dépasser date/ dépasser date

/ demander main d'oeuvre/ disponibil ité main d'oeuvre/ disponibil ité main d'oeuvre/ dépasser date/ dépasser date

en attente de pièce de rechange

en attente de main d'oeuvre

bloqué

/ Trouver Faille

/ aucune fail le trouvée

/ Annuler

/ Convertir en BT

/ observation

Acceptée

engagée

refusée Historiée

Annulée

Crée

Figure V-2 : Diagramme état-transition de l’objet DT

Rawdha Mabrouki

56

L’un des personnels travaillant avec une machine de production peut créer une demande de

production. Alors cette demande peut être soit accepté soit elle est annulée. Si le service de

maintenance à accepter cette demande il peut la dirigée vers l’équipe de maintenance qui peut

générer un ordre de travail ou refuser la demande si l’équipement est de faible importance et de

grand âge.

[Oui]

Responsable Secteur Responsable Maintenance Technicien Direction Financière

[Non]

[Non]

[Oui]

[Non]

[Oui]

[Non]

[Oui]

[Oui][Oui]

Demander Travail

Consulter DT

Générer OT

Planifier MP

BT

éditée

Planifier programme d'intervention

Affecter TechnicienAffecter Budget Affecter TechnicienAffecter Budget

Contrôle de Budget

Budget dépassé

?

Annuler réapprovisionnement

Approbation

OT bloqué

réapprovisionnement

OT Urgente

enregistrement des coûts

enregistrer coût de main d'ouvre enregistré coût de pièces

enregistrer coût de main d'ouvre enregistré coût de pièces

Clôture de OT

Archiver BT

Gérer intervention

Vérification Stock

Numéro Pièce

disponible

Numéro Pièce

disponible

Numéro Pièce

disponible

Réservation pièce

Disponible

?

demander réapprovisionnement

édition BT

Enregistrer consommationEnregistrer consommation

Vérifier Budget

Budget suffisant

Actualisation Budget

Rejeter demande d'achat

Générer Rapport

Figure V-3 : Diagramme activité gestion des ordres de travail

Rawdha Mabrouki

57

La figure ci-dessus illustre le diagramme d’activité de demande de travail de maintenance.

Raffinement du cas d’utilisation gérer ordres de travail’

L’ordre de travail est l’une des entités les plus compliqués dans le GMAO. Car elle peut être

crée, planifiée, mises en attentes externalisé etc.

Ce qui ne caractérise pas réellement ce cas d’utilisation en un CRUD. Nous pouvons la

considérée comme une variation de CRUD, que nous avons nommée SFCRUD, pour Search,

Filter, Create, Update, Delete. Nous avons donc raffiné le cas d’utilisation gérer ordres de

Figure V-4 : Diagramme d'activité demander travail

Figure V-5 : Diagramme de cas d’utilisation gérer les ordres de travail

<<Extend>>

<<Extend>>

<<Extend>>

<<Extend>>

<<Extend>>

<<extend>>

Responsable d

'équipes

maintenance

Manager Maintenance

Consulter la liste des

Ordres de travailGérer les Ordres de

travail

Chercher un ordre

de travail

Filter les ordre

de travail

Consulter un Ordre

de Travail

Mettre à jour un Orde

de Travail

Supprimer un ordre

de Travail

Consulter la liste des

OT non Planifié

Consulter la liste des

OT planifiés

Consulter la liste de

tous les OT

Ajouter un Ordre de

Travail

Rawdha Mabrouki

58

travail afin de définir les interfaces utilisateur. La figure V-5 illustre le diagramme de cas

d’utilisation gérer les ordres de travail. Donc à partir de ce cas l’utilisateur peut consulter les

OT planifiés et non planifier afin qu’il puisse identifier les OT en retards. Ainsi que l’utilisateur

peut imprimer un OT.

Raffinement du cas d’utilisation gérer demandes travail

La gestion des demandes de travail inclut les cas d’utilisation CRUD et les cas chercher

demande, filtrer la liste des demandes.

La figure ci-dessus illustre le diagramme de cas d’utilisation gérer les demandes de travail.

L’utilisateur peut consulter la liste des demandes de travail. Soit il consulte la liste des

demandes refusées ou les demandes engagées. Il peut ainsi réaliser des actions de recherche,

filtrage. Il peut notifier une panne.

V.4. Conception détaillé

Au niveau de la conception générale nous avons raffiné les cas d’utilisation relatifs aux Sprint

2. Suivant la liste des User Stories, nous pouvons donc spécifier les cas d’utilisations détaillés.

Raffinement du cas d’utilisation consulter ordre de travail

Afin de raffiner le cas d’utilisation consulter un ordre de travail nous avons utilisé le

diagramme de cas d’utilisation. La figure V-7 illustre le raffinement de cas. Alors une fois le

responsable sélectionne un ordre de travail dans la listePage, il peut visualiser tous ses détails,

puis modifier ses informations. Il peut ainsi élaborer un contrat d’externalisation. Il peut aussi

<<Extend>>

<<Extend>>

<<Extend>>

<<Extend>>

<<Extend>>

<<extend>>

<<extend>>

Responsable Secteur

Gérer les demandes travail Consulter la liste des

demandes travail

chercher une demande

filter la liste des demandes

Consulter détails d'une demande

Modifier une demande

Supprimer une demande

Consulter la liste de demande réfusées

Consulter la liste des demandes engagées

Notifier Panne

générer ordre de travail

Figure V-6 : Diagramme de cas d’utilisation gérer les demandes de travail

Rawdha Mabrouki

59

mettre à jour son statut. Ainsi qu’il peut ajouter des interventions. Il peut imprimer la fiche

d’OT. Les cas d’utilisation imprimer fiche d’OT est un cas d’utilisation relative au Sprint 4.

Raffinement du cas d’utilisation ajouter ordre de travail

D’après le diagramme d’activité gestion des ordres de travail illustré sur la figure VI-1, l’ordre

de travail provient de deux sources : la génération à partir d’une demande de travail suite à une

observation et le plan de la maintenance préventive qui la déclenche automatiquement. Nous

avons détaillé le cas d’utilisation nominale et commun pour les deux sources ainsi que nous

allons détailler les variations entre les deux. Nous allons utiliser le diagramme de séquence et

la description textuelle des deux scénarios afin de modéliser ces deux cas d’utilisation :

Identification cas n°1 : Ajouter ordre de travail

Acteur principal : Responsable de maintenance

Objectif : après le déclenchement d’une maintenance préventive ou l’acceptation d’une demande,

le responsable de maintenance doit fournir tous les informations exigés et obligatoires d’un ordre

de travail.

Précondition : une notification ou alerte de demande ou activation d’un préventif, s’affiche dès

que le responsable se connecte au module

Dialogues

Scénario nominal

1. Le responsable clique sur la proposition d’ordre,

2. Le système charge l’interface de choix de type d’ordre,

3. Le responsable choisi le type d’ordre et valide le choix,

4. Le système crée un ordre de travail avec les champs existants dans la demande,

5. Il charge l’interface de modification d’ordre de travail et invite l’utilisateur à compléter les

autres champs.

<<extend>>

<<extend>>

<<extend>>

<<extend>>

<<extend>>

Responsable

maintenance

Consulter Ordre de Travail

Mettre à jour Statu OT

Imprimer Fiche d'OT

gérer intervention

Modifier ordre de

travail

Externaliser ordre de

travail

Figure V-7 : Diagramme de cas d’utilisation consulter ordre de travail

Rawdha Mabrouki

60

6. Le responsable maintenance ajout les dates et l’objectif.

7. Le système demande l’utilisateur d’enregistrer l’ordre,

8. Le responsable valide et quitte le formulaire,

9. Le système exécute la mise à jour de l’ordre de travail.

Alternatives

A1 : la date est expirée : le système affiche un message afin de consulter la source de

proposition. Puis le système revient au scénario 1.

Scénario d’erreur

A1 : les dates de l’ordre de travail sont inférieures ou égales à la date du système : le système

revient vers le scénario 4.

Contrainte d’ajout : le numéro OT est obligatoire. La date de début de travail est supérieure ou

égale à la date de création de demande.

Fin et Post-condition : ordre de travail est créé et trié avec les OT non planifié.

Compléments

Convivialité : Le formulaire d’ajout et de modification de l’ordre de travail doit indiquer les

champs obligatoires à remplir. Ainsi qu’il doit être un formulaire rapide à remplir et ne contient

pas plusieurs champs détaillés.

La figure ci-dessus illustre le diagramme de séquence nominale d’ajout d’un OT. Ce

diagramme illustre le scénario commun, qui peut se dérouler suite à trois évènements :

déclenchement d’un travail préventif ou génération à partir d’une demande ou proposition d’un

ordre de travail.

Identification cas n°2 : Générer ordre de travail

Figure V-8 : Diagramme de séquence nominale d'ajout d'un OT

Rawdha Mabrouki

61

Acteur principal : Responsable de maintenance,

Objectif : après l’acceptation d’une demande d’intervention, le responsable de maintenance doit

fournir tous les informations exigés et obligatoires d’un ordre de travail,

Précondition : le responsable sélectionne la demande de travail portant un statu accepté.

Dialogues

Scénario nominal

1. Le responsable consulte la liste des demandes de travail acceptées afin de les engager.

2. Le responsable sélectionne une demande et il clique sur le bouton engagé demande.

3. Le système charge le formulaire d’ajout d’ordre de travail en spécifiant la demande,

4. Le système modifie le statut de la demande à engagé,

5. Exécution de cas n°1

Scénario d’erreur

A1 : la date d’expiration de l’ordre de travail est incorrecte.

Compléments

Convivialité : le bouton générer ordre de travail doit être visible sur l’interface de gestion de la

demande. Et dans le cas d’un OT provenant du déclenchement d’une maintenance préventive,

l’alerte doit être visible pour le responsable.

Le diagramme de séquence d’ajout d’un OT suite à une demande est celui le cas d’utilisation

générer OT dans le diagramme de cas d’utilisation consulter demande de travail. Après l’envoi

du message envoyé (Datedemande, typeDemande…) le système exécute la référence au

scénarion nominal AjouterOT.

Figure V-9: Diagramme séquence de génération d'un OT suite à une Demande

Rawdha Mabrouki

62

Raffinement du cas d’utilisation consulter demande

Si l’utilisateur a choisi de consulter la liste des demandes de travail, il peut vérifier tous les

champs saisis puis remplir les autres champs qui représentent plus de détail de la demande et

afin de raffiner le cas d’utilisation consulter détails d’une demande nous avons utilisé le

diagramme des cas d’utilisation. La figure ci-dessus illustre le diagramme de cas d’utilisation

consulter demande travail. Le raffinement de ce cas d’utilisation nous a produites d’autres cas :

générer ordre de travail et imprimer fiche de mode de défaillance et analyse des effets et

modifier demande.

Raffinement de cas d’utilisation demander Travail

Le cas d’utilisation métier Demander travail est présenté en tant que scénario nominale.

Figure V-10 : Diagramme de cas d’utilisation consulter demande travail

<<Extend>>

<<Extend>>

<<extend>>

Responsable

maintenance

Responsable

secteur

Consulter demande Travail

générer ordre Travail

imprimer fiche de mode de défaillances et

analyse des effets

Modifier demande de

travail

Responsable secteur

<<ListPage>>

ListDemandeTravail

<<DropDialog>>

demande travail

<<entity>>

DemandeTravail

<<entity>>

AssetTable

<<MasterDetails>>

modifier demande

SequenceDiagram_DemanderTravail

5: Mettre à jour statu équipement(statu = en Panne)

Update()

2: Remplir champs date arret, objectif

3: modifier champs et enregistré4: Create(NumDT,AssetTable)

1: Cliquer sur Bouton 'Notifier Observation'

6: Afficher détails demande

7: Remplir les champs de détails de la demande

8: Valider mise a jour

Figure V-11 : Diagramme de séquence demander travail

Rawdha Mabrouki

63

La figure V-11 illustre de diagramme de séquence Demander Travail. Alors à partir de ce

diagramme de séquence nous pouvons repérer les entités participantes, Demande de Travail et

AssetTable. Ainsi que nous pouvons identifier les interfaces utilisateur ListDemandeTravail et.

Identification cas n°3 : Demander travail

Acteur principal : le responsable de secteur de production.

Objectif : à tout moment, le responsable secteur doit avoir accéder à la liste des demandes de

travail, accéder au formulaire de demande de travail où il peut saisir les coordonnés d’une panne

ou une observation en attendant une réponse de responsable de maintenance si la panne n’est

pas critique.

Précondition : l’équipement en question doit exister dans la table des immobilisations afin de

le sélectionner en tant qu’objet de demande.

Dialogues

Scénario nominal

1. Le responsable ajoute une nouvelle demande.

2. Le système crée une demande avec un identifiant automatique.

3. Le responsable secteur choisi un équipement comme objet de maintenance.

Il saisit les coordonnées de panne (date arrêt et objectif demande).

Il spécifie la date de réforme de l’équipement exigée.

Il enregistre les informations.

4. Le système affiche un récapitulatif de la demande.

Il envoie une notification de demande au responsable maintenance.

Il modifie le statu de l’équipement à en panne.

5. L’utilisateur peut consulter la demande afin de mettre à jour des champs plus détaillés.

6. Le système affiche la page de type Master Détails.

7. L’utilisateur peut mettre à jour les champs manquants.

8. Le système enregistre les mises à jour.

Scénario optionnel

3.1 le responsable veut sélectionner la pièce qui cause la panne.

3.2 le système affiche les pièces détachées.

3.3 le responsable choisi la pièce (ou pièces) en question.

Alternatives

2. a le responsable annule la demande.

2. b le système change l’état de la demande à annulée.

Scénario d’erreur

A1 : Les champs obligatoires ne sont pas correctement saisis. Le système reprend le

scénario 3.

A2 : le champ date et heure de panne est supérieur ou égale à la date système. Le système

reprend le scénario 3.

Champs : la date et heure de la panne doit être inférieur strictement à la date Système.

Exception : enregistrement pas réussi.

Fin et Post-condition : une nouvelle demande a été enregistrée avec un statu crée et transmise

au service de maintenance, et une notification de nouvelle demande est créée pour le groupe des

Rawdha Mabrouki

64

agents de maintenance. Et la pièce en panne est enregistrée dans le système en spécifiant sa

criticité.

Compléments

Ergonomie : l’enregistrement de la demande doit être rapide, ainsi que la mise à jour.

Raffinement de cas d’utilisation gérer les interventions

Afin de gérer les interventions le technicien indique lesquelles des interventions est réalisée

afin qu’il passe à une autre intervention jusqu’à valider la totalité de son travail. Le technicien

en tant qu’acteur qui consulte l’application seulement pour valider l’avancement de son travail

et enregistrer les consommations a des privilèges retreints.

La figure ci-dessus illustre le cas d’utilisation gérer interventions. Afin de valider son travail le

technicien a besoin d’imprimer le bon de travail, alors ce cas d’utilisation sera détailler dans le

Sprint 3 relatif au reporting.

Raffinement de cas d’utilisation affecter techniciens

Le module des ressources humaines détaillé dans l’annexe B fournit la fonction de gestion des

personnels dans les termes de gestion d’absence, gestion des compétences etc. Nous allons donc

utiliser ces fonctionnalités existantes afin qu’il soit adapté à notre module.

Le responsable de maintenance ou chef d’équipe, afin de rédiger un ordre de travail doivent

visualiser la disponibilité des techniciens, puis ils peuvent réaffecter le travail si l’un des

Valider checklist

enregistrer consommation

imprimer bon de travailTechnicien

Figure V-12 : Diagramme de cas d'utilisation gérer les interventions

Figure V-13 : Diagramme de cas d'utilisation affecter techniciens

Chef équipe

visualiser disponibilité

technicien

réaffecter travail

Vérifier compétences

Rawdha Mabrouki

65

techniciens est absent. La figure V-13 illustre le diagramme de cas d’utilisation affecter

techniciens.

Raffinement de cas d’utilisation gérer les contrats

Cette fonctionnalité doit permettre un suivi précis et efficace de tous les contrats. Elle doit ainsi

garantir l’ajout d’un nouveau fournisseur et la commande du service de maintenance.

La figure ci-dessus illustre le diagramme de cas d’utilisation gestion des contrats de

maintenance. L’utilisateur peut dans ce cas consulter un contrat, ajouter, modifier supprimer ou

ajouter un consultant. Nous allons détailler le cas d’utilisation ajouter contrat avec la description

textuelle. La figure

Identification cas n°4 : Ajouter contrat

Acteur principal : le responsable maintenance

Objectif : à tout moment, le responsable de maintenance peut ajouter un contrat de maintenance

à chaque fois qu‘une décision d’externalisation est prise. Il doit avoir accéder au formulaire

d’ajout de gestion de contrat ou de gestion des ordres de travail. Il doit saisir les champs

obligatoires décrivant un contrat.

Précondition : l’ordre de travail en question doit exister afin de l’externaliser.

Dialogues

Scénario nominal

1. Le responsable clique sur externaliser ordre, puis il consulte le formulaire d’ajout de

contrat,

2. Le système affiche la liste des contrats dans la page SimpleListDetails Liste Contrat,

3. Le système met à jour le statu de l’ordre de travail à externalisé,

4. Le responsable clique sur ajouter contrat,

Il saisit les coordonnées du contrat,

Il choisit l’accord et le fournisseur,

Il valide le formulaire,

Figure V-14 : Diagramme de cas d'utilisation gestion des contrats de maintenance

<<Extend>>

<<Extend>>

<<Extend>>

<<Extend>>

<<Extend>>

Responsable maintenance

Gestion des Contrats

Consulter la liste des Contrats

Consulter détails Contrats

Modifier Contrat

Supprimer Contrat

Ajouter nouveau Contrat

Commander Service

Rawdha Mabrouki

66

5. Le système affiche un récapitulatif de la demande.

Il réalise l’action de création du contrat avec les champs obligatoires saisie.

Scénario optionnel

3.1 le responsable veut sélectionner la pièce qui cause la panne.

3.2 le système affiche les pièces détachées.

3.3 le responsable choisi la pièce (ou pièces) en question.

Alternatives

2. a le responsable choisie un

2. b le système change l’état de la demande à annulée.

Scénario d’erreur

A1 : Les champs obligatoires ne sont pas correctement saisis. Le système reprend le

scénario 3.

Exception : enregistrement pas réussi.

Fin et Post-condition : un nouveau contrat pour l’ordre de travail est créé avec un statu

externalisé.

La figure ci-dessus illustre le diagramme de séquence d’ajout d’un contrat de maintenance. À

partir de ce diagramme nous avons repérer les entités participantes : OrdreTravail,

AgreementHeader, VendTable et Contrat.

Figure V-15 : Diagramme de séquence d'ajout d'un contrat de maintenance

Rawdha Mabrouki

67

Diagramme de classes

Le diagramme de classe de la conception détaillé (cf. FigureVI-16) nous rapproche de plus en

plus du codage. Alors notre objectif est de mettre en place une base de données utilisée à des

fins d’analyse, elle doit permettre la traçabilité des informations et des décisions prises et

données datés. Nous pouvons générer le schéma de la base de (cf. Figure VI-17). L’utilisateur

peut élaborer une demande de travail de maintenance (GmaoDemande). La demande peut être

demandée pour une unité de production (OMOperationUnit) et par un seul demandeur

(HCMWorker, module gestion des RH). Puis chaque demande peut être convertie en un ordres

de travail GmaoOrdreTravail). Donc l’ordre provient d’une et une seule demande. L’ordre de

travail à une catégories de coûts (COSLedgerTable module contrôle de gestion). Chaque ordre

de travail contient un objet qui nécessite un service, un type de maintenance relié

(GmaoPréventive, Gmaocorrective, Gmaoaméliorative) et peut être affecté ou pas à un

responsable (HCMWorker). Afin de garantir l’extensibilité de notre module nous avons créé

les autres types de prévention : conditionnel et systématique et prédictive. Chaque ordre de

travail est constitué de zéro ou plusieurs interventions ordonnancées. L’ordonnancement des

interventions consiste à affecter un technicien (HCMworker) selon ses compétences

(HCMSkills, module gestion RH) à chaque intervention (GmaoIntervention) en planifiant les

dates de début et de fin. Le technicien pendant son intervention peut enregistrer la

consommation des pièces de rechange sur la ligne d’intervention (GmaoLigneIntervention).

Alors une intervention est constituée d’une ou plusieurs lignes d’intervention, et une ligne

d’intervention appartient à une seule intervention. La consommation est soit un achat

(PurchTable module Approvisionnement) ou provient du magasin (InventTable module gestion

des entrepôts).

D’une autre part le responsable de maintenance peut planifier des préventions en choisissant le

diagramme de Gantt relatif (GanttTable module master planning) qui est lié à la classe

WrkControlTable (module master planning). La maintenance préventive doit être créée en

séquence d’étape ou checklist (classe étape). Une étape peut être de plusieurs types

(Lubrification, sécurité …). Chaque instance de la classe GmaoContrat provient d’un ordre et

doit avoir une instance de la classe AgreementHeader (module gestion de service). Cette

dernière doit être créée pour une seule instance de la classe VendTable (module accounts

payable). Afin de planifier un ordre de travail, la classe GmaoOrdre doit avoir une référence à

la classe PlanReference. PlanActivity, PlanActivityTime et Plan ( module master planning)

Rawdha Mabrouki

68

0..*

1..1

1..11..*

1..1

0..*

0..*

1..1

0..1

0..*

1..1

0..*

0..*

1..1

1..1

0..*

1..1

0..1

1..1

0..*

1..1 0..*

1..1

0..*

0..1

0..*

0..1

1..1

0..1

0..*

0..1

0..*

0..1

0..*

1..1

1..*

1..1

0..*

0..*

Ordered

0..1

0..1

0..*

*1..1

0..*1..1

0..*

1..1

0..1

0..*

0..1

0..*

GmaoOrdreTravail

+

+

-

+

+

+

+

+

+

+

+

+

+

+

+

NuméroOT

TypeOT

Datecréation

Description

coutOTestime

coutOTreel

statusOrdreTravail

BudgetOT

DateExpiration

NombrePersonneRequit

NiveauMaintennace

urgence

coûtMaintd'Ouevre

coûtMatériel

Objectif

: string

: string

: DateTime

: string

: decimal

: decimal

: decimal

: decimal

: DateTime

: decimal

: string

: string

: decimal

: decimal

: string

GmaoPreventive

+

-NumPreventive

TypeIntervale: string

: String

GmaoConditionnelle

+ NumCondi : string

GmaoPrédictive

+ NumPredictive : string

GmaoSystèmatique

+ NumSys : string

GmaoCorrective

+

+

+

+

+

NumCorrectif

TypeCorrectif

NoteDiagnostic

NoteRepatation

NoteControle

: string

: string

: string

: string

: string

GmaoAméliorative

+

-

-

NumInterventionAme

CauseAMelio

TypeAmelio

: string

: string

: string

AssetTable+ AssetId : string

HCMWorker

+

-

-

-

reqId

coût($/H)

Partitien

PersonelNumber

: int

: decimal

: String

: String

HCMSkill+

+

HcmWorker

reqIdSkill

: int

: string

GMAOPièceDétaché

+

+

-

NumPièceDétaché

Défectueuse

Anomalie

: string

: bool

: String

GmaoIntervention

-

+

+

-

-

-

-

-

-

NumIntervention

DateDeb

DateFin

TypeTravail

Charge

Description

Objectif

statuIntervention

coutInter

: String

: DateTime

: decimal

: String

: int

: String

: String

: String

: decimal

étapes

+

+

+

NumEtape

TypeEtape

Priorité

: string

: string

: stringpneumatique

+

+

+

+

+

+

+

+

+

+

+

+

+

TypePneumatique

PressionCircuitPrincipal

debitCircuitPrincipal

FiltrePneumatique

debitCircuitSecondaire

PressionCircuitSecondaire

HumiditePneumatiq

étatCircuit

FuitePneumatique

ValveSureté

ValveAir

BruitPneumatique

autrePneumatiq

: string

: decimal

: decimal

: decimal

: decimal

: decimal

: decimal

: string

: bool

: string

: string

: bool

: string

Sécurité

+

+

+

+

+

Protecteur

Detecteur

affichage

Avertisseur

autreSecru

: bool

: bool

: bool

: bool

: string

mecanique

+

+

+

+

+

+

+

+

+

tensionCouroies

usureChaine

souplesseMaille

allongement

assemblage

connectionsFiletes

glissieres

refroidissement

autreMecaniq

: decimal

: bool

: bool

: bool

: string

: string

: string

: string

: string

electricite

+

+

+

+

+

+

+

+

+

+

+

Volts

amps

RPM

VibrationMoteur

CircuitElectriique

commandes

batteries

température

tempsReponse

nettoyageMoteur

autreElectri

: decimal

: decimal

: decimal

: bool

: string

: string

: string

: decimal

: decimal

: string

: string

Lubrification

+

+

+

TypeLubrification

Lubrifiant

QtyLubrifiant

: string

: string

: decimal

GmapLigneIntervention

+

+

+

-

NumLigneIntervention

NoteLigne

enregistréPar

Complété

: String

: int

: String

: bool

InventTable

+

+

+

ItemId

NumGroupId

ItemPriceToleranceGroupId

: String

: int

: decimal

GmaoDemande

+

+

+

+

+

+

+

+

-

-

-

-

-

-

-

-

-

-

-

NuméroDemande

DateDemande

TypeDemande

NoteDemande

DateCréation

ObservationDem

unitéProduction

DateRéforme

CauseDefaillance

CriticitePanne

Detectabilite

Symptomes

Priorite

Gravite

Occurence

EffetSurEquipement

EffetSurPersonne

EffetSurSystem

EffetSurProduction

: string

: DateTime

: string

: string

: DateTime

: String

: string

: DateTime

: String

: String

: String

: String

: String

: String

: String

: String

: String

: String

: String

OMOperationUnit

+

-

-

OMOperatingUnitNumber

OMOperatingUnitType

HCMWorker

: String

: String

: String

COSLedgerTable

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

AccountNumber

AccountName

AllowDimension

Blocked

CostCategoryId

CostType

CostUnit

CreditDimension

DebitDimension

Dimension

MandatoryDimension

ProjCategoryId

UnitId

UnitModule

UnitPurpose

: String

: String

: bool

: bool

: int

: String

: intString

: float

: float

: String

: String

: int

: int

: String

: String

PlanActivity

+

+

+

+

+

+

PlanActivtyId

activityTime

FreightedBy

Name

OnattandUpdate

PlanActivityType

: decimal

: int

: int

: String

: String

: String

PlanReference

+

+

+

+

+

+

PlanRefrence

ControlingORganisme

DefaultDimension

PlanDescription

PlanName

PlanType

: decimal

: String

: int

: int

: String

: String

PlanActivityTime

+

+

RessourceQuantity

QuantityUnitOfMesure

: String

: intplan

+

+

+

+

ValidFrom

ValidTo

VersionNum

Status

: DateTime

: DateTime

: DateTime

: String

GmaoContrat

+

+

-

-

DateExpirationGuaranti

titreContrat

NumContrat

StatuContrat

: DateTime

: String

: String

: String

AgreementHeader

+

-

-

-

-

-

-

-

-

NumLigneCouverture

agreementState

currency

effectiveDate

ExpirationDate

LineType

DocumentTitle

IsDeleted

Originator

: String

: String

: String

: DateTime

: DateTime

: int

: String

: Int16

: Int64VendTable

+

+

+

+

VendAccount

PaymTermId

PaymDayId

Party

: int

: int

: int

: String

AgreementClassification

+

+

-

AgreementRelationType

IsImmutable

AgreementName

: decimal

: int

: String

GantTable

+

+

+

GanttSchedIdd

NameG

TimeFence

: int

: String

: DateTime

WrkCtrTable

+

+

+

+

+

WrkCtrId

NameCtr

SetupTime

Worker

WrkctrType

: int

: string

: DateTime

: Int64

: string

GanttLine

+

+

+

GanttScheId

LineNum

WrkctrId

: int

: int

: int

PurchTable

+

+

+

PurchId

Partition

ItemPriceToleranceGroupId

: int

: String

: decimal

Figure V-16 : Diagramme de classes

Rawdha Mabrouki

69

GmaoOrdreTravail

NuméroOT

AssetId

NuméroDemande

AccountNumber

TypeOT

Datecréation

Description

coutOTestime

coutOTreel

statusOrdreTravail

BudgetOT

DateExpiration

NombrePersonneRequit

NiveauMaintennace

urgence

coûtMaintd'Ouevre

coûtMatériel

Objectif

varchar(254)

varchar(254)

varchar(254)

int

varchar(254)

datetime

varchar(254)

decimal

decimal

decimal

decimal

datetime

decimal

varchar(254)

varchar(254)

decimal

decimal

varchar(254)

<pk>

<fk1>

<fk1>

<fk2>

GmaoPreventive

NuméroOT

NumPreventive

GanttSchedIdd

TypeIntervale

varchar(254)

varchar(254)

int

varchar(254)

<pk,fk2>

<pk>

<fk1>

GmaoConditionnelle

NuméroOT

NumPreventive

NumCondi

varchar(254)

varchar(254)

varchar(254)

<pk,fk>

<pk,fk>

<pk>

GmaoPrédictive

NuméroOT

NumPreventive

NumPredictive

varchar(254)

varchar(254)

varchar(254)

<pk,fk>

<pk,fk>

<pk>

GmaoSystèmatique

NuméroOT

NumPreventive

NumSys

varchar(254)

varchar(254)

varchar(254)

<pk,fk>

<pk,fk>

<pk>

GmaoCorrective

NuméroOT

NumCorrectif

TypeCorrectif

NoteDiagnostic

NoteRepatation

NoteControle

varchar(254)

varchar(254)

varchar(254)

varchar(254)

varchar(254)

varchar(254)

<pk,fk>

<pk>

GmaoAméliorative

NuméroOT

NumInterventionAme

CauseAMelio

TypeAmelio

varchar(254)

varchar(254)

varchar(254)

varchar(254)

<pk,fk>

<pk>

AssetTable

AssetId varchar(254) <pk>

HCMWorker

reqId

reqIdSkill

HcmWorker

NuméroOT

coût($/H)

Partitien

PersonelNumber

int

varchar(254)

int

varchar(254)

decimal

varchar(254)

varchar(254)

<pk>

<fk1>

<fk1>

<fk2>

HCMSkill

HcmWorker

reqIdSkill

int

varchar(254)

<pk>

<pk>

GMAOPièceDétaché

AssetId

NumPièceDétaché

Défectueuse

Anomalie

varchar(254)

varchar(254)

bit

varchar(254)

<pk,fk>

<pk>

GmaoIntervention

NuméroOT

reqId

NumIntervention

DateDeb

DateFin

TypeTravail

Charge

Description

Objectif

statuIntervention

coutInter

varchar(254)

int

varchar(254)

datetime

decimal

varchar(254)

int

varchar(254)

varchar(254)

varchar(254)

decimal

<pk,fk1>

<fk2>

pneumatique

NuméroOT

NumPreventive

TypePneumatique

PressionCircuitPrincipal

debitCircuitPrincipal

FiltrePneumatique

debitCircuitSecondaire

PressionCircuitSecondaire

HumiditePneumatiq

étatCircuit

FuitePneumatique

ValveSureté

ValveAir

BruitPneumatique

autrePneumatiq

NumEtape

TypeEtape

Priorité

varchar(254)

varchar(254)

varchar(254)

decimal

decimal

decimal

decimal

decimal

decimal

varchar(254)

bit

varchar(254)

varchar(254)

bit

varchar(254)

varchar(254)

varchar(254)

varchar(254)

<fk>

<fk>

Sécurité

NuméroOT

NumPreventive

Protecteur

Detecteur

affichage

Avertisseur

autreSecru

NumEtape

TypeEtape

Priorité

varchar(254)

varchar(254)

bit

bit

bit

bit

varchar(254)

varchar(254)

varchar(254)

varchar(254)

<fk>

<fk>

mecanique

NuméroOT

NumPreventive

tensionCouroies

usureChaine

souplesseMaille

allongement

assemblage

connectionsFiletes

glissieres

refroidissement

autreMecaniq

NumEtape

TypeEtape

Priorité

varchar(254)

varchar(254)

decimal

bit

bit

bit

varchar(254)

varchar(254)

varchar(254)

varchar(254)

varchar(254)

varchar(254)

varchar(254)

varchar(254)

<fk>

<fk>

electricite

NuméroOT

NumPreventive

Volts

amps

RPM

VibrationMoteur

CircuitElectriique

commandes

batteries

température

tempsReponse

nettoyageMoteur

autreElectri

NumEtape

TypeEtape

Priorité

varchar(254)

varchar(254)

decimal

decimal

decimal

bit

varchar(254)

varchar(254)

varchar(254)

decimal

decimal

varchar(254)

varchar(254)

varchar(254)

varchar(254)

varchar(254)

<fk>

<fk>

Lubrification

NuméroOT

NumPreventive

TypeLubrification

Lubrifiant

QtyLubrifiant

NumEtape

TypeEtape

Priorité

varchar(254)

varchar(254)

varchar(254)

varchar(254)

decimal

varchar(254)

varchar(254)

varchar(254)

<fk>

<fk>

GmapLigneIntervention

NuméroOT

NumLigneIntervention

ItemId

NoteLigne

enregistréPar

Complété

varchar(254)

varchar(254)

varchar(254)

int

varchar(254)

bit

<pk,fk1>

<pk>

<fk2>

InventTable

ItemId

NumGroupId

ItemPriceToleranceGroupId

varchar(254)

int

decimal

<pk>

GmaoDemande

AssetId

NuméroDemande

reqId

OMOperatingUnitNumber

NuméroOT

DateDemande

TypeDemande

NoteDemande

DateCréation

ObservationDem

unitéProduction

DateRéforme

CauseDefaillance

CriticitePanne

Detectabilite

Symptomes

Priorite

Gravite

Occurence

EffetSurEquipement

EffetSurPersonne

EffetSurSystem

EffetSurProduction

varchar(254)

varchar(254)

int

varchar(254)

varchar(254)

datetime

varchar(254)

varchar(254)

datetime

varchar(254)

varchar(254)

datetime

varchar(254)

varchar(254)

varchar(254)

varchar(254)

varchar(254)

varchar(254)

varchar(254)

varchar(254)

varchar(254)

varchar(254)

varchar(254)

<pk,fk4>

<pk>

<fk1>

<fk3>

<fk2>

OMOperationUnit

OMOperatingUnitNumber

OMOperatingUnitType

HCMWorker

varchar(254)

varchar(254)

varchar(254)

<pk>

COSLedgerTable

AccountNumber

AccountName

AllowDimension

Blocked

CostCategoryId

CostType

CostUnit

CreditDimension

DebitDimension

Dimension

MandatoryDimension

ProjCategoryId

UnitId

UnitModule

UnitPurpose

int

int

int

int

int

int

int

int

int

int

int

int

int

int

int

<pk>

PlanActivity

PlanActivtyId

RessourceQuantity

QuantityUnitOfMesure

activityTime

FreightedBy

Name

OnattandUpdate

PlanActivityType

decimal

varchar(254)

int

int

int

varchar(254)

varchar(254)

varchar(254)

<pk>

<fk>

<fk>

PlanReference

PlanRefrence

NuméroOT

ControlingORganisme

DefaultDimension

PlanDescription

PlanName

PlanType

decimal

varchar(254)

varchar(254)

int

int

varchar(254)

varchar(254)

<pk>

<fk>

PlanActivityTime

RessourceQuantity

QuantityUnitOfMesure

varchar(254)

int

<pk>

<pk>plan

ValidFrom

ValidTo

VersionNum

PlanRefrence

PlanActivtyId

Status

datetime

datetime

datetime

decimal

decimal

varchar(254)

<pk>

<pk>

<pk>

<fk1>

<fk2>

GmaoContrat

DateExpirationGuaranti

NuméroOT

titreContrat

NumContrat

StatuContrat

datetime

varchar(254)

varchar(254)

varchar(254)

varchar(254)

<pk>

<fk>

AgreementHeader

NumLigneCouverture

DateExpirationGuaranti

agreementState

currency

effectiveDate

ExpirationDate

LineType

DocumentTitle

IsDeleted

Originator

varchar(254)

datetime

varchar(254)

varchar(254)

datetime

datetime

int

varchar(254)

smallint

bigint

<pk>

<fk>

VendTable

NumLigneCouverture

VendAccount

Ven_NumLigneCouverture

Ven_VendAccount

PaymTermId

PaymDayId

Party

varchar(254)

int

varchar(254)

int

int

int

varchar(254)

<pk,fk2>

<pk>

<fk1>

<fk1>

AgreementClassification

AgreementRelationType

NumLigneCouverture

IsImmutable

AgreementName

decimal

varchar(254)

int

varchar(254)

<pk>

<fk>

GantTable

GanttSchedIdd

NameG

TimeFence

int

varchar(254)

datetime

<pk,ak>

WrkCtrTable

WrkCtrId

LineNum

GanttScheId

NameCtr

SetupTime

Worker

WrkctrType

int

int

int

varchar(254)

datetime

bigint

varchar(254)

<pk>

<fk>

<fk>

GanttLine

GanttScheId

LineNum

GanttSchedIdd

WrkctrId

int

int

int

int

<pk>

<pk>

<fk>

PurchTable

PurchId

NuméroOT

NumLigneIntervention

Partition

ItemPriceToleranceGroupId

int

varchar(254)

varchar(254)

varchar(254)

decimal

<pk>

<fk>

<fk>

Figure V-17 : Schéma relationnel de la base de données

Rawdha Mabrouki

70

Flux de travail de l’ordre de travail

Afin d’établir le workflow de processus de gestion de l’ordre de travail. Nous allons réaliser la

modélisation du flux de travail en utilisant le langage de notation BPMN

La figure ci-dessus illustre le diagramme de flux de travail du processus de gestion de l’ordre

de travail modélisé avec le langage BPMN. Alors le responsable de maintenance après la

création de l’ordre de travail doit opprobre le travail afin de le mettre à jour avec l’ajout des

interventions. Enfin l’ordre de travail va être clôturé.

V.5. Design de l’expérience utilisateur

L’un des problèmes posés au début est la formation des utilisateurs du GMAO. Nous avons

proposé de résoudre ce problème avec le choix des interfaces utilisateur uniques et semblables

à l’expérience utilisateur des autres modules d’Ax. Alors pour définir ce design nous avons

besoin des prototypes, qui nous aident à définir le type d’interface pour chaque entité ou pour

chaque diagramme de séquence établie. Ainsi que ces prototypes permettent de mieux identifier

la navigation entre les différentes IHM. Enfin le prototypage est un outil qui aide à cerner les

histoires techniques de Sprint.

Figure V-18 : Flux de travail du processus de gestion d'ordre de

travail

Rawdha Mabrouki

71

La figure ci-dessus illustre le prototype de la page de zone de notre futur module. Nous avons

choisi de mettre les interfaces les plus utilisées sur le menu courant, tel que la liste des ordres

de travail, la liste des ordres de travail non planifiés, les contrats etc.

La figure ci-dessus illustre le prototype de formulaire d’ordonnancement des interventions.

L’ordonnancement doit fournir toutes les informations relatives ou travail de maintenance :

l’équipement, la demande et l’ordre de travail. Nous voulant créer un IHM qui permet de gérer

les interventions sur une grilles qui affiche toutes les interventions, les techniciens et le statu de

l’intervention si elles sont finies ou pas.

Figure V-20 : Aperçu du prototype : la page de zone

Figure V-19 : Prototype de l'interface d'ordonnancement des interventions

Rawdha Mabrouki

72

V.6. Réalisation

Avant de présenter les interfaces IHM nous allons présenter quelques remarques sur la base de

données créées. Puisque Dynamics Ax supporte l’héritage, nous avons créé les tables filles

GmaoPreventif, GmaoConditionnel, GmaoCorrectif, GmaoSystematique, GmaoAméliorative

et GmaoPredictive qui héritent de la table mère nommée GmaoOrdreT.

La figure ci-dessus illustre un aperçu sur les tables qui hérite de la table GmaoOrdreTravail

avec leurs champs partagés entre les tables filles.

Afin de présenter notre travail nous allons exposer quelques interfaces utilisateur réalisés. Nous

allons démarrer avec les interfaces relatives à la gestion de demande travail. Puis nous allons

détailler les interfaces de gestion des ordres de travail et ordonnancement des travaux. Enfin

nous présentant les interfaces de gestion des interventions, de gestion des contrats ainsi que les

cas de reporting réalisés.

Figure V-21 : Héritage de la table mère GmaoOrdreTravail

Rawdha Mabrouki

73

Interfaces de gestion de demande de travail

Avant de développer la liste de demande de travail nous devons d’abord développer les

formulaires master détails et ajouter nouvelle demande afin de les propulser sur la ListPage.

La figure ci-dessus illustre la ListPage des demandes de travail. Cet interface répond au besoin

exprimer au niveau de cas d’utilisation gérer les demandes de travail. L’interface est constituée

d’une grille listant tous les demandes de toutes natures. En cliquant sur un enregistrement de la

grille l’utilisateur est dirigé vers la consultation de la demande. À droite de la grille nous avons

ajouté un Lookup qui permet à l’utilisateur de visualiser un résumé de la demande sans

consulter ses détails. En haut nous trouvons aussi le panneau d’action qui porte plusieurs

boutons.

1. Bouton modifier permet d’accéder à une demande sélectionner en mode update.

2. Ensemble de boutons qui permettent de supprimer une demande sélectionner de la grille

ou la modifier dans la grille, ou la consulter en mode lecture.

3. Bouton notifier panne permet d’ajouter une nouvelle demande en remplissant seulement

les champs obligatoires définissant la demande.

4. Bouton générer ordre de travail permet d’ajouter un ordre à partir de la demande

sélectionnée.

Figure V-22 : Interface ListPage de demande de travail

Rawdha Mabrouki

74

La figure ci-dessus illustre l’interface de type Master Détails de demande de travail. Nous avons

choisi ce type d’interface mieux que l’interface de type Transactionnel Détails vue que la

demande et une entité de type master et ne contient pas des données transactionnelles. Le bouton

mettre à jour statu demande permet comme le leur nom indique permet d’ouvrir un DropDialog

qui permet de modifier le statut de la demande. Ainsi que le bouton modifier permet

d’enregistrer les modifications et passer en mode lecture.

Cette interface est constituée des FactBox :

Général : est constitué des champs de saisis des informations de la demande tel que

l’observation, l’équipement objet de demande, type de demande statu et sa priorité ainsi

qu’une note sur le travail demandé.

Information demande : est constituées champs relatifs à la demande tel que le demandeur,

la date demande et la date de fin travail prévisionnelle, ainsi que des informations

administratives en lecture seule tel que le créateur et la date de création.

Analyse AMDEC : permet de données des informations sur la panne, sur sa gravité, son

occurrence et sa détectabilité afin de calculé sa criticité. Puis l’utilisateur peut donner des

informations sur la cause et effet de la panne.

Figure V-23 : Interface DropDialog de mise à jour de statu demande

Rawdha Mabrouki

75

Le pattern d’interface Master Détails que nous avons choisi d’utiliser pour de gérer les

demandes de travail nous permet aussi de créer une interface de modification dans la grille ce

qui enrichie l’expérience utilisateur. La figure ci-dessus illustre l’interface de modification des

demandes de travail dans la grille. Si l’utilisateur choisi de générer un ordre de travail le

système lui affiche l’interface de choix de forme de maintenance.

La figure ci-dessus illustre l’interface de choix de forme de maintenance afin de créer une

instance type d’un ordre.

Figure V-25 : Interface Master Détails modification des demandes dans la grille

Figure V-24 : Interface de choix d'un ordre de travail

Rawdha Mabrouki

76

La figure ci-dessus illustre un DropDialog qui permet de générer un ordre de travail à partir de

la demande sélectionnée. Les champs demande et équipement sont remplis automatiquement,

l’utilisateur peut donc ajouter l’objectif et la date de début de l’ordre puis cliquer sur Ok.

Interfaces de gestion des ordres de travail

Les interfaces de gestion d’ordre de travail sont la ListPage, Master Détails et Transactional

Détails.

Alors la figure ci-dessus illustre l’interface liste des ordres de travail. Cet interface est constitué

d’un panneau d’action groupant les boutons de mise ajour de la liste (supprimer modifier dans

la grille et bouton modifier qui mène vers les détails d’un ordre de travail sélectionner) et un

bouton Aperçu avant impression qui permet d’imprimer l’ordre de travail.

Figure V-26 : Interface de génération d'un OT à partir d'un DT

Figure V-27 : Interface List page de gestion des ordres de travail

Rawdha Mabrouki

77

La figure ci-dessous illustre l’interface de consultation d’un ordre de travail. Le statu de l’ordre

de travail est visible en haut de la page ce qui simplifie le suivie de l’ordre. Cette interface est

constituée des FastTabs : Générale, coût et dates et planification. Le FastTab générale contient

deux liens vers la demande et l’équipement objet de maintenance.

Le panneau d’action est constitué des boutons :

1. Groupe de bouton de gestion de l’ordre : modifier, supprimer.

2. Ajouter un ordre de travail : permet de charger l’interface de proposition d’un nouvel ordre.

3. Intervention : permet de charger l’interface d’ordonnancement d’intervention.

4. Externaliser ordre : permet de charger l’interface gestion des contrats de maintenance.

Si l’utilisateur clique sur le bouton modifier il pourra modifier les champs du formulaire. La

figure ci-dessus illustre l’interface de modification d’un ordre de travail. L’utilisateur peut

valider les modifications qu’il a effectuées en cliquant encore sur le bouton modifier.

Figure V-28 : Interface de consultation d’ordres de travail

Figure V-29 : Interface de modification d'un ordre de travail

Rawdha Mabrouki

78

Interfaces d’ordonnancement d’intervention

Le responsable de maintenance peut planifier et ordonnancer les interventions pour chaque

technicien en utilisant l’interface d’ordonnancement des interventions. Cet interface est

constitué de deux vues : vue en-tête et vue ligne.

La figure ci-dessus illustre l’interface d’ordonnancement des interventions (type Transactional

détails). L’entête de l’interface regroupe les détails de l’équipement, demande, ordres et

planification de maintenance. La ligne d’ordre de travail est constituée d’une grille qui permet

de gérer les techniciens et leurs interventions.

La figure ci-dessus illustre la vue en-tête de l’interface d’ordonnancement d’interventions. Si

la forme d’ordre est corrective alors seulement les champs relatifs à l’ordre correctif sont activés

et les autres sont désactivés

Figure V-30 : Interface d'ordonnancement d'intervention vue ligne

Figure V-31 : Interface d’ordonnancement d’intervention

Rawdha Mabrouki

79

Afin de gérer les interventions le technicien peut ajouter des lignes d’interventions et cocher les

lignes complétées. Il peut ainsi cocher les pièces en pannes et saisir l’anomalie. La figure ci-

dessus illustre la réalisation du cas d’utilisation gérer intervention. Sur le panneau d’action nous

avons ajouté le bouton demander achat d’une pièce de rechange.

Interfaces d’affectation techniciens

Le cas d’utilisation gestion d’intervention relatif au responsable est réaliser par une interface

de type Simple Détails. Il est constitué d’une grille qui affiche la liste de l’intervention affectée

à chaque technicien et chaque type de travail.

La figure ci-dessus illustre le formulaire de gestion des interventions. L’utilisateur peut gérer

les interventions et planifier la charge et les dates. Il peut ainsi cliquer sur les boutons :

1. Absence qui affiche les absences du technicien

2. Vérifier compétences : permet de réaliser un test de matching de type travail et les

compétences du technicien afin de savoir s’il est adéquat pour le travail.

3. Consulter travail : permet de consulter la progression du travail du technicien.

Figure V-32 : Interface de gestion d'intervention

Figure V-33 : Interface d’affectation de technicien

Rawdha Mabrouki

80

Interfaces de gestion des contrats de maintenance

D’abord nous avons créé les nouvelles tables et leurs relations avec les tables existantes. Nous

avons réussi à réaliser les interfaces des contrats de maintenance : interfaces d’ajout et interface

de gestion des contrats.

La figure ci-dessus illustre l’interface de gestion des contrats de maintenance. L’utilisateur peut

cliquer sur le bouton commande service, il peut effectuer toutes les actions de gestion de

l’accord avec le fournisseur. Ainsi que l’utilisateur peut ajouter, modifier et supprimer un

contrat sélectionné sur la grille.

La figure ci-dessus illustre l’interface d’ajout d’un nouveau contrat de maintenance en cliquant

sur le bouton externaliser ordre dans la page de consultation de l’ordre. L’utilisateur peut cliquer

sur le menu accord il peut donc choisir l’accord déjà établi.

Figure V-34 : Interface de gestion des contrats de maintenance

Figure V-35 : Interface d'ajout d'un contrat de maintenance

Rawdha Mabrouki

81

Impression des documents de maintenance

L’utilisateur peut cliquer sur le bouton aperçu avant impression sur la page de consultation d’un

ordre de travail. Il peut imprimer l’ordre de travail.

La figure ci-dessus illustre la réalisation du cas d’utilisation imprimer ordre de travail.

Le responsable de maintenance à l’exécution de son travail, il peut imprimer les interventions

avec leurs affectations. La figure ci-dessus illustre l’impression du rapport des interventions.

V.7. Conclusion

Nous avons réalisé la spécification des besoins, la conception et le développement de sous-

module de gestion des ordres de travail. Puis nous avons réalisé la conception et développement

des interface de gestion des contrats de maintenance. Et nous avons réalisé la conception du

flux de travail de gestion de l’ordre de travail. Ensuite nous avons étudier les modules de control

de coût, la planification de Dynamics Ax. Ainsi que nous avons créé quelque rapport de

maintenance. Enfin nous avons planifié la réalisation du Sprint 4 qui consiste à créer le reporting

et les clés de performance

Figure V-37 : Impression des interventions

Figure V-36 : Impression de l'ordre de travail

Rawdha Mabrouki

82

Conclusion générale

L’objectif principal de ce projet, propos dans le cadre d’un stage d’ingénieur, était de concevoir

et de réaliser un module Dynamics Ax de gestion de maintenance assisté par ordinateur

(GMAO) pour les entreprises industrielles. Le problème des GMAO c’est qu’ils sont coûteux

et difficiles à intégrer au sein du système d’information de l’entreprise. Ils existent une panoplie

de progiciels commercialisés du GMAO. Les difficultés sont liées au choix du progiciel

adéquat. Nous avons choisi comme solution de développer un module GMAO autour de l’ERP

Microsoft Dynamics Ax. Nous avons réussi à développer des interfaces utilisateurs simples qui

suit les patterns de Dynamics Ax afin de garantir l’unicité de l’expérience utilisateur.

Notamment pour résoudre les problèmes d’intégration, nous avons défini les processus

communiquant avec notre GMAO en utilisant la cartographie des processus. Et au niveau de la

conception détaillé nous avons identifié qu’elle table de l’existant communique avec les

nouvelles tables des processus du GMAO.

Nous avons réussi à étendre le module immobilisation afin qu’il réponde au besoin de gestion

des équipements de production. Nous avons ainsi réussi à développer la gestion de demande de

travail, la gestion des ordres de travail la gestion des interventions des techniciens de

maintenance et l’ordonnancement des interventions. Nous avons donc garantie le cœur d’un

GMAO. Puis nous avons réalisé les interfaces de gestion des contrats planification et flux de

travail.

Ensuite au niveau du management, nous avons utilisé la méthode de management Scrum. Nous

avons essayé tout au long de notre travail de construire notre module Sprint par Sprint. Nous

nous sommes rendu compte de l’importance de l’organisation d’un projet de développement

sur Ax.

Ce stage de fin d’étude nous a permis de découvrir un environnement professionnel différent

de nos expériences précédentes. Pendant cette période nous avons profité de l’expérience

professionnelle de nos encadrants, d’une part d’approfondir nos connaissances en conception

des systèmes d’informations et d’autre part de renforcer notre expérience en développement

des modules MDX en termes de gestion de projet, en terme fonctionnel et technique. Alors

après cinq mois de stage au sein de la société Cynapsys nous avons passé par les étapes

Rawdha Mabrouki

83

préliminaires démarrant par les études préalables ainsi qu’une montée en compétence sur

Microsoft Dynamics Ax.

Cependant deux problèmes ont eu lieu lors de déroulement de projet. Le premier problème est

lié à la compréhension des objectifs de l’application dans son ensemble. Ceux-ci se sont

clarifiés au fur et à mesure de l’avancement des Sprints. Ce problème est répercuté sur la

planification du dernier Sprint qui consiste à développer les KPI et la réalisation du reporting.

En fait nous avons sous-estimé la complexité et temps lié à ce Sprint. Nous pouvant le planifier

en 30 jours. Malgré toutes les difficultés rencontrées au niveau de la spécification des exigences

et les contraintes de temps, nous avons réalisé une division satisfaisante et en préparant la

documentation nécessaire.

Néanmoins notre GMAO peut être amélioré. Nous proposant de développer une application

mobile qui permet les techniciens de gérer leurs interventions en utilisant une tablette, ce qui

simplifie ces tâches. D’un autre part nous pouvons lier notre module à des contrôleurs et des

capteurs qui déclenchent des événements si une panne survienne. Cette solution augmentera

l’automatisation de gestion des ordres de travail. Nous avons déjà préparé les tables adéquates

à cette extension (les tables Intervention prédictive et conditionnelle). Nous pouvons ajouter

des conditions selon les évènements déclenchés ou prédire des pannes selon les mesures des

capteurs.

Rawdha Mabrouki

I

Bibliographies

AFNOR La Norme AFNOR [En ligne]. - 2016. - 15 03 2016. - http://www.afnor.org/.

Birch Keith Dunkinson, Andrew Implementing Microsoft Dynamics Ax 2012 with Sure Step

2012 [Ouvrage] / éd. 978-1-84968-704-1 ISBN. - BIRMINGHAM : PACKT, enterprise,

2013. - Vol. www.packtpub.com.

Blokdijk Gerard Microsoft Dynamics - Simple Steps to Win, Insights and Opportunities [En

ligne]. - 03 2015. - ISBN 978-1-84968-704-1. - 18 05 2016. - http://PacktLib.PacktPub.com.

Bourque Pierre Richard R. (Dick) Fairley SWEBOK V3.0 Guide to the software Engineering

Body of Knowledge [Ouvrage]. - [s.l.] : IEEE computer society, 2014.

Bufferne Jean le guide de la TPM Total Productive Maintenance [En ligne]. - 2006. - ISBN :

2-7081-3723-9. - 18 03 2016. - www.editions-organisation.com.

Chambon J. jchambon.fr/ [En ligne]. - 2016. - 24 7 2016. - http://jchambon.fr/.

DAVID PARMENTER Developing, Implementing, Key Performance indicator [En ligne] //

wiley. - wiley. - ISBN 978-0-470-54515-7. - 2016. - www.wiley.com.

Fayol Henri Administration industrielle et générale [Ouvrage]. - [s.l.] : Dunod, 1916.

Jerrel Blankenship Matthew Bussa, et Scott Millett Pro Agile .NET Development with

Scrum [Ouvrage] / éd. www.springeronline.com. - New York : Springer, 2011. - Vol.

ISBN:978-1-4302-3534-7 : p. 381.

Luszczak Andreas Using Microsoft Dynamics AX 2012: Updated for Version R3 [En ligne]. -

2015. - 2 06 2016. - www.springer.com.

Marc St-Marseille Jean-Bruno Lapointe la gestion des équipements vers l'entretien préventif

[Ouvrage]. - [s.l.] : Bibliothèque nationale du Québec, 1997.

Ministére de l'économie des finances et de l'industrie les métiers de maintenance industrielle,

[En ligne]. - 2001. - http://www.mistereFinance.fr.

Mobley R. Keith ROOT CAUSE FAILURE [En ligne]. - 1999. - ISBN 0-7506-7 158-0. - 25

4 2016. - http://www.newnespress.com.

Rawdha Mabrouki

II

Mohammed Rasheed Erkend Dalen Learning MS Dynamics Ax 2012 Programming

[Ouvrage]. - [s.l.] : PACKT, enterprise, 2014.

Nathalie Lopez Jorge Migueis et Emmanuel Pichon Intégrer UML dans vos projets

[Ouvrage]. - [s.l.] : www.Eyrolles.com, 2000. - p. 258.

Official Training Dynamics, Microsoft Materials for Microsoft MASTER PLANNING IN

MICROSOFT DYNAMICS® AX 2012 [En ligne] // https://www.microsoft.com/en-

us/learning/course.aspx?cid=80423. - 2012. - 24 05 2016.

Okungbowa Andrew SAP ERP Financial Accounting and Controlling: Configuration and Use

Management [En ligne]. - 2015. - ISBN : 978-1-4842-0716-1. - 12 04 2016. -

www.springeronline.com.

orléans-tours Centre d’information et d’orientation académie Les métiers de l’informatique

dossier n°9 [Ouvrage]. - [s.l.] : Université François-Ramelais, 2012.

R.Keith Mobley Lindley R.Higgins and Darrin J.Wikoff Maintenance Engineering

Handbook [Ouvrage]. - 2008 : McGRAW_HILL.

Rota Véronique Messager Gestion de projet agiles [Ouvrage]. - [s.l.] : Eyrolles, 2010.

Seba Drifa Merise : Concept et mise en œuvre [Ouvrage]. - [s.l.] : ENI, 2003.

Shelly Gary B.Harry J. Rosenblatt Systems Analysis and Design [Ouvrage]. - [s.l.] : Course

Technology, Cengage Learning, 2012.

Siegel Scott E. Donaldson Stanley G. Successful Software Development [Ouvrage]. - [s.l.] :

Prentice Hall PTR, 2000.

Simha R.Magal, Jeffrey Word Integrated Business Processes with ERP systems [Ouvrage]. -

[s.l.] : Wiley, 2011.

solution Oracle E-Business Optimize Asset Utilization Enterprise Asset Management

[Rapport]. - [s.l.] : Oracle Data sheet, 2015.

Team The microsoft Dynamics Ax Inside Microsoft Dynamics Ax [Ouvrage] / éd.

http://www.microsoft.com/learning/booksurvey.. - [s.l.] : Microsoft Press, 2012. - Vol. ISBN:

978-0-7356-6710-5 : p. 784.

Thomas F.Wallace Michael H.Kremzar ERP: MAking It Happen, the Implementers' Guide

to Success with Entreprise Resource Planning [Ouvrage]. - [s.l.] : Wiley, 2001.

Rawdha Mabrouki

III

Thomas F.Wallace, Michael H.Kremzar ERP: Making It Happen, the Implementers' Guide

to Success with Entreprise Resource Planning [Ouvrage]. - [s.l.] : Wiley, 2001.

Waslawick Raul sidnei Object-Oriented Analysis, Modeling with UML, OCL, IFML [En

ligne] // elsevier. - elsevier, 2014. - ISBN: 9780124186736. - 25 03 2016. - http://elsevier.com.

William W. Cato R. Keith Mobley Computer-Managed Maintenance Systems [Ouvrage]. -

[s.l.] : Plant Engineering, 2002.

Withee Ken Microsoft Business Intelligence for Dummies [En ligne]. - 2010. - ISBN: 978-0-

470-52693-4. - 05 04 2016. - www.wiley.com/.

Rawdha Mabrouki

IV

Webographie

[W1] http://www.cynapsys.de/consulter le 18/02/2016

[W2] http://www.tunisiait.com/consulter le 18/02/2016

[W3] http://www.it-expertise.com/consulter le 2/03/2016

[W4] http://www.economie.gouv.fr/consulter le 7/03/2016

[W5] http://www.piloter.org/consulter le 28/03/2016

[W6] http://www.computerwoche.de/ consulter le 5/04/2016

[W7] http://www.maintenance-industrielle-sud.com/ consulter le 6/04/2016

[W8] https://www.dynaway.com/ consulter le 11/04/2016

[W9] https://technet.microsoft.com/consulter le 13/04/2016

Rawdha Mabrouki

V

Glossaire

ESN est une société experte dans le domaine des nouvelles technologies numérique et de l’informatique.

Elle peut englober plusieurs métiers (conseil, conception et réalisation d’outils, maintenance ou encore

formation) et a pour objectif principal d’accompagner une société cliente dans la réalisation d’un projet.

Offshore, outsourcing ou externalisation offshore concerne une délocalisation des services vers des

pays étrangers éloignés. Le Near shore outsourcing ou externalisation Near shore est une autre forme

d’externalisation des services. Il s’agit de recourir à des prestataires locaux, c'est-à-dire implantés sur le

territoire national ou à des sous-traitants bénéficiant d’une proximité moyenne.

CMMI est un modèle de référence, un ensemble structuré de bonnes pratiques, destiné à appréhender,

évaluer et améliorer les activités des entreprises d'ingénierie.

ISO 9001 fait partie de la série des normes ISO 9000, relatives aux systèmes de gestion de la qualité,

elle donne les exigences organisationnelles requises pour l'existence d'un système de gestion de la

qualité.

Système embarqué, c’est un système électronique, piloté par un logiciel qui est complètement intégré

au système qu'il contrôle. C’est un système électronique soumis à diverses contraintes.

Écoconception est un terme désignant la volonté de concevoir des produits respectant les principes du

développement durable et de l'environnement.

Modèle : Un modèle est une représentation d’un phénomène de monde réel de telle sorte qu'il peut

répondre à des questions sur le phénomène avec une certaine tolérance acceptable et prévisible.

Systèmes adaptatifs complexes (CAS) sont des systèmes caractérisés par des comportements

complexes qui résultent des interactions non linéaires entre un grand nombre de composants dans le

temps et l'espace à différents niveaux d'organisation on peut donner à titre d’exemple : L'écosystème, le

cerveau le système immunitaire et la Société.

Expérience utilisateur, UX, user expérience recouvre la façon dont un site web ou une application est

perçue par ses utilisateurs en fonctions de ses qualités ergonomiques, de navigation et de contenu elle

joue un rôle très important dans l’efficacité d’un site web ou d’une application et constitue également

un facteur de fidélisation.

B2B Business to Business terme utiliser dans le commerce interentreprises, c’est échangé entre deux

entreprises de transaction, et des actions de vente et achat suivent des procédures et sur Internet.

Rawdha Mabrouki

VI

NF EN 13306 X 60-319 : Terminologie de la maintenance (indice de classement : X 60-319). De

L’Association Française de Normalisation (AFNOR). C’est l’organisation française qui représente la

France auprès de l’Organisation Internationale de Normalisation (ISO) et du Comité européen de

normalisation (CEN).

Périodicité d’usage est le nombre d’heures de travail ou compteur de production de l’équipement.

La stratégie TPM a été initiée au Japon dans les années 1970 et s’inscrit dans une stratégie du zéro délai,

zéro stock et zéro panne. Elle met l’accent sur l’organisation des ressources productives pour améliorer

la disponibilité des équipements.

AMDEC en anglais FMECA (Failure Mode, Effects and Criticality Analysis) est une technique

d’analyse qui part de l’examen des causes possibles de défaillance des éléments d’un système pour

aboutir aux effets de ce système

Disponibilité des équipements est l’aptitude d’un bien à être en état d’accomplir une fonction requise

dans des conditions données, à un instant donné ou durant un intervalle de temps donné, en supposant

que la fourniture des moyens extérieurs est assurée.

Interopérabilité est la capacité d’un programme informatique ou d’un fichier de données à s’adapter à

plusieurs plates formes matérielles et logicielles. Par exemple, le passage de données comptables d’une

filiale dans un environnement Microsoft Access vers la consolidation sur une base de données Oracle

sera un bon test d’interopérabilité des deux systèmes informatiques.

Cardinalité : nombre d’occurrence minimale et maximale.

CRUD, est un pattern de conception permettant de regrouper les actions de gestion par rapport aux cas

d’utilisation métier. Ils sont souvent liés à interroger la base de données.

Base de données relationnelle dans laquelle les données sont stockées dans des tables, selon le modèle

introduit par Codd. La base de données consiste en deux ou plusieurs tables reliées par des relations.

Cette base de données et interrogé par des opérations d’algèbre relationnelle.

Base de données multidimensionnelle sont le plus souvent formées par agrégats de bases hétérogènes

et pouvant être relationnelles. Les données ainsi agrégées peuvent être analysées avec un nouveau type

d’outil, caractérisée par une dimension (contexte du fait : type, date, lieu, groupe) et une mesure (quantité

descriptive). Ce type de base de données propose d’analyser des indicateurs numériques (par exemple

chiffre d’affaires, nombre d’individus, ratios, etc.).

Métadonnées est un modèle d’un modèle, le méta modélisation consiste à analyser, construire et à

développer des patterns des règles des cadres et des contraintes.

Rawdha Mabrouki

VII

ANNEXES

Annexe A

Liste des documentations et reporting

Processus Documents et Rapport

Gestion de stocks Bon de sortie de magasin

Demande d’achat

État mensuel des stocks

État annuel des stocks

Fiche d’identification fournisseur

Fiche d’identification pièce

Liste des consommables en stock

Liste des fournisseurs

Mouvement et niveau du stock

Gestion économique Fiche de budget prévisionnel

Fiche des opérations budgétaires

Fiche des taux horaires d’arrêt

Fiche des budgets récapitulatifs

Rapport mensuel maintenance

Gestion des équipements États des indisponibilités

Fiche de découpage d’équipement

Fiche de prévision des contrôles

Fiche de prévision des visites

Fiche technique

Fiche technique de graissage

Fiche historique

Nomenclature des pièces détachées

Tableau de diagnostic

Liste accessoires de l’équipement

Liste outillages de l’équipement

Gestion des ordres de

travail

Bon de travail

Compte rendu de contrôle

Demande de main-d’œuvre

Programme de révision

Fiche de réparation

Rapport maintenance systématique

Rapport d’inspection

Fiche d’entretien préventif

Historique des réparations

Rawdha Mabrouki

VIII

Annexe B

Aperçu de l’architecture Modulaire de Dynamics Ax

Les modules existants sur la plateforme Dynamics Ax sont les modules GRH, de gestion

financière, modules SCM, modules de gestion des projets enfin les modules CRM.

Ressources humaine

Le module ressources humaines est constitué de sous-modules : Administration de processus

de recrutement, administration des absences, gestion de compétences, gestion de performance

de travail et gestion des formations (Luszczak, 2015).

Administration d’organisations

Le module est dit en anglais « Organization administration » est le module qui permet de créer

des souches de numéros en spécifiant l’entité juridique (Luszczak, 2015).

Approvisionnement

Le module en anglais « Procurement and sourcing », permet de créer des stratégies d’achat

pour contrôler le processus métier d’approvisionnement. Il permet d’identifier les fournisseurs,

d’intégrer les nouveaux fournisseurs, de commander des articles et des services, de mettre à

jour les commandes fournisseur et de confirmer la réception des produits (Luszczak, 2015).

Comptabilité

Le module en anglais « General ledger », le module comptabilité permet de définir et de gérer

tous les enregistrements financiers de l’entreprise (Luszczak, 2015).

Comptabilité fournisseurs

Le module en anglais est dit « Accounts Payable ». Il communique avec le module

approvisionnement (achat). Le module comptabilité fournisseur permet d’effectuer le suivi des

factures fournisseur et des dépenses sortantes (Luszczak, 2015).

Comptabilité clients

Le module est dit en anglais « Accounts receivable ». C’est le module Ventes qui permet

d’assurer le suivi des paiements entrants et des factures client (Luszczak, 2015).

Budgétisation

Rawdha Mabrouki

IX

Le module budgétisation permet de paramétrer, créer des brouillons de budget et d’afficher des

budgets. Nous allons paramétrer ce module pour contrôler le coût de maintenance des actifs

d’une entreprise en utilisant le formulaire BudgetControlConfiguration. En effet ce module

permet de valider, calculer et contrôler les coûts des transactions effectués (Luszczak, 2015).

Gestion des fonds et des banques

Le module « Cash and Bank Management », permet de mettre à jour les comptes bancaires de

l’entité juridique et les instruments financiers qui y sont associés (Luszczak, 2015).

Voyages et dépenses

Le module de gestion de déplacements et des dépenses permet de créer un workflow intégré

dans lequel se stocke les informations de mode de paiement, et les importations des transactions

de carte de crédit. L’utilisateur peut effectuer le suivi de l’argent dépensé par les employés

lorsqu’ils exposent leurs dépenses dans un voyage (Luszczak, 2015).

Gestion de projets et comptabilité

Le module gestion de projet sert à planifier, et contrôler des projets pour l’entreprise. Ce module

permet également de gérer les coûts des projets internes et d’investissement (Luszczak, 2015).

Immobilisation

Le module en anglais est « Fixed assets ». Les immobilisations sont des articles de valeur

(bâtiments, véhicules, terrains et équipements et capitaux intangibles tel que les droits d’auteurs

et marques). Sous Dynamics Ax, nous trouvons la gestion des immobilisations non acquises,

acquises vendues ou mise à rebut. Nous voulons par notre projet d’ajouter la gestion des

équipements de productions, disponibles et les équipements en pannes (Luszczak, 2015).

Planification

Le module en anglais « Master planning » appartient à la SCM. Il gère la planification et

l’ordonnancement des ressources et matériels qui permettent de réaliser la production. Il est

hautement intégré sur plusieurs autres modules tel que les modules de finance (Official

Training, 2012). Il permet de créer les calendriers prévisionnels afin de calculer les besoins

bruts de la demande prévue (Luszczak, 2015). Le module est constitué de trois processus de

planification : Master scheduling, Forecast scheduling et Intercompany master scheduling

(Official Training, 2012).

Rawdha Mabrouki

X

Contrôle de production

Le module contrôle de production appartient au module SCM. Il permet de suivre les activités

de production, de planifier la production. Il permet de suivre les matières et la consommation

de gamme. Il enregistre la rétroaction de production, et aide à suivre les mouvements de stock

et coût de production (Luszczak, 2015).

Gestion d’informations sur les produits

Le module gestion d’information sur les produits permet de gérer les produits et variantes de

produits (Luszczak, 2015).

Contrôle de gestion

Le contrôle de gestion consiste à suivre, à enregistrer et à analyser les coûts associés aux

produits ou aux activités d’une organisation (Luszczak, 2015).

Conformité et contrôles internes

Le module « Compliance and internal control », inclut les fonctionnalités de durabilité

environnementale et d’audit (Luszczak, 2015).

Gestion des services

Le module « Service management », est un module qui permet d’établir des accords de service

et des services récurrents de traiter des commandes et des demandes de renseignements de

clients. Ainsi qu’il permet de gérer et analyser la fourniture de services aux clients.

Gestion de stock et gestion des entrepots

Les deux modules SCM (Warehouse management, Inventory management) : permettent

respectivement de contrôler les stocks et gérer les entrepôts.

Rawdha Mabrouki

XI

Annexe C

Product Backlog

Story ID Titre User story Priorité Sprint #

1 Reporting des OT Imprimer les ordres de travail à chaque fois qu'il est

validé

3 3

2 Génération des OT

Les ordres de travail peuvent être générer, suivant une

planification

1 2

3

Affectation des

interventions

Les demandes sont gérées par le responsable ainsi qu'il

effectue l’ordre à un technicien

1 2

4

Identification

uniques

Les identifiants des équipements sont générés

automatiquement par le système selon le secteur

3 1

5 Affichage trié Trier les équipements par leur criticité 3 1

6 Arborescence

Pour chaque équipement, il a une arborescence, chaque

pièce détachée a alors un identifiant unique,

2 1

7 Suivre intervention Suivie des interventions par équipement 3 1

8

Visualisation des

OT

Le responsable de maintenance veut seulement

visualiser les OT actives 3 1

9 Planifier MP

L’utilisateur peut sélectionner un équipement, il

planifie un OT préventive

2 1

10

Plusieurs

compteurs

équipement

Nombre illimité de compteurs paramétrables par

équipement

3 1

11

État de

l'équipement

Codification visuelle de l’état équipement (disponible,

en fonctionnement, dégradé, à l’arrêt

3 1

12

Criticité de

l’équipement

Évaluer la criticité de l'équipement 1 1

13

Modification des

programmes

Calendrier par intervenant avec gestion des exceptions

(congés, maladies, formations …)

2 2

14

Compétences des

techniciens

Définition des rôles / qualifications des intervenants 2 2

15 Taux horaire par

intervenant

Taux horaire par intervenant 2 2

16

Fonction de

recherche multi

critères

Fonction de recherche multi critères 3 2

17 Recevoir demande

de travail

Impression et/ou envoi par email automatique des DI 3 2

18 Suivie des DI Suivi par statut des DI (acceptée – convertie en bon de

travail –engagée – clôturée – refusée)

1 2

19 Gestion des

priorités des DI

Le responsable peut gérer les priorités des DI 2 2

20 Date souhaitée/

Date début de

panne

Le responsable secteur doit indiquer la Date souhaitée/

Date début de panne

1 2

21 Temps passé /

Temps

d’indisponibilité

Temps passé / Temps d’indisponibilité 3 2

Rawdha Mabrouki

XII

22 Planification en

mode graphique

Synthèse graphique et par tableau des charges et

ressources sur une période donnée

2 2

23 Le technicien doit

indiquer

l'avancement

État d’avancement bon de travail 2 2

24 Gestion des

documents

Association de fichiers joints à un bon de travail 3 2

25 Gestion des

documents

Association de fichiers joints à une maintenance

préventive

3 2

26 Gestion de coûts Temps et coût prévu 2 2

27 Planifier pièce de

rechange

Article(s) nécessaire (s) 2 2

28 Type d'intervention Définition des types d’intervention 1 2

29 Planifier MP Planification selon des compteurs (nombre illimité de

compteurs pour un même équipement

3 2

30 Gestion des achats Le technicien peut demander l'achat 2 2

31 Planifier pièce de

rechange

Pour chaque panne, enregistrer les pièces de rechange 2 2

32 Séquence de

maintenance

Une séquence de maintenance est définie lorsqu’une

intervention préventive pré-planifiée doit être effectuée

sur un objet

3 3

33 Gestion d'ordre de

travail

Une fois la demande traitée, un bouton permet de

transformer la demande en ordre

1 2

34 Ordre de travail Chaque ordre de travail contient un objet qui nécessite

un service et un type de maintenance relié.

1 2

35 Ordonnancement

des interventions

Prise en charge du BT par l'agent création itérative

d'interventions possible si nécessaire

1 2

36 Ordonnancement

des interventions

Rapport d'intervention et déclaration terminé par

l'agent, notification du responsable de maintenance et

de production qui a notifié

3 2

37 Workflow Un workflow est connecté à un ordre de travail. 3 3

38 Contrat de

maintenance

Recherche des OT transformé en contrat de

maintenance (externalisé à un sous-traitant)

3 3

39 Impression des DT Reporting et documentation des demandes de travail 3 3

40 KPI économiques KPI des couts des ordres de travail 3 3

41 KPI de temps KPI de temps et de l'efficacité de l'équipement 3 3

صيانة المعدات الصناعية ضمن مايكروسوفت دايناميكس أي أكس تطبيق إلدارة تطوير العنوان: تصميم و

ندسة اإلعالمية في المدرسة العليا للعلوم التطبيقية والتصرف. تقرير التربص مقدم ضمن متطلبات نيل يتمثل هذا الكتاب في تقرير تربص لمشروع ختم الدراسة في ه :تلخيصالتربص في الشركة سينبسيس أستاذ مساعد. وقد تم هذا يامنة السايب تحت إشراف المؤطر ,علوم االعالمية تخصص الهندسة االعالمية شهادة الهندسة في ميدان التكوين في

ق ائد فريق دت نت و استشاري مايكروسوفت دايناميكس أكس. الهدف من هذا التربص يتمثل في تطوير نظم لمساعدة مسؤولي المؤطر عالء الدين عزيز تحت إشراف تخطيط جداول الصيانة بأكثر صيانة المعدات الصناعية بمساعدة الحاسوب. كما أنه يسمح للعاملين بوحدات التصنيع ل صيانة معدات الصناعة. هذا النظم يسمى إدارة وظيفة

يف باهضة. وقد تم تطوير هذه ف اعلية وتحديد تنفيذ أعمال الصيانة. ثم إن هذه النظم تجنب فشل تشخيص االعطاب الغير متوقعة التي يمكن أن تسبب إنقطاع اإلنتاج وتكالمايكروسوفت دايناميكس أي أكس يمد المبرمج بمناهج وونماذج تقنية . 3اإلصدار 2012النظم ضمن نظام تخطيط موارد المؤسسات مايكروسوفت دايناميكس أي أكس

قد تم توظيف , صممت لمساعدة الشركات في تطوير الخدمات الذكية والسريعة. خالل هذا المشروع حلول و نظم تخطيط موارد المؤسسات الرئيسية فهو عبارة عن ,ووظيفية .تعملنا أيضاً اكس++ كلغة برمجة، و تم أيضاً إستعمال مرفيكس كبيئة للتطويراس ,سكروم كمنهجية إلدارة تخطيط دورات التطوير

.سكروم، نظام تخطيط موارد المؤسسات ، مرفيكس، اكس++ ,صيانة معدات الصناعة ,مايكروسوفت دايناميكس أي أكس : مف اتيح

Microsoft Dynamics AX.TITRE : Conception et développement d’un module GMAO autour de l’ERP

Résumé : Les systèmes de gestion de maintenance des équipements collectent et gère les données sur l’état et la disponibilité des

équipements des usines. Cela permet aux opérateurs des unités d’usine de planifier des calendriers de maintenance plus efficace,

en évitant à la fois les diagnostiques et pannes inattendues des équipements, qui peuvent provoquer des interruptions coûteuses

en temps de production. Les progiciels de gestion de maintenance recueillissent les données pour assurer une disponibilité

maximale de production et avec un minimum d’intervention humaine. Ces progiciels sont connus sous le nom GMAO Gestion

de Maintenance Assisté par ordinateur. Le présent rapport a été rédigé dans le cadre du stage de fin d’étude effectué à Cynapsys

de période de six mois. Le but de ce stage est l’obtention de diplôme d’ingénieur en Ingénierie Informatique au sein de SESAME.

L’objectif du projet est de réaliser un module GMAO autour de l’ERP Microsoft Dynamics Ax 2012 R3. Ce module doit favoriser

la gestion des demandes, ordres et intervention de maintenance ainsi que la planification, coordination et communication des

intervenants de maintenance. Nous avons exploité les technologies Microsoft fournit avec Ax : SQL server 2014 en tant que

SGBD, X++ en tant que langage de programmation et MorphX en tant qu’IDE. La gestion de ce projet est inspirée de la

méthodologie Scrum.

Mots clés : planification, GMAO, ordre de travail, Microsoft Dynamics Ax, Scrum, SQL Server 2014, MorphX, X++.

TITLE: Design and development of a CMMS Module around the Microsoft Dynamics AX ERP.

Abstract: CMMS (Computerized Maintenance Management Systems) or EAM (Asset management system) also referred to industrial and plant

asset management, collect and manage data on the condition and availability of major plant equipment in discrete and process manufacturing

plants. This enables plant operators to plan maintenance schedules more effectively avoiding both unnecessary equipment inspections and

unexpected breakdowns, which can cause expensive interruptions in production time. CMMS gather data in real-time to ensure maximum

production uptime and throughput, with a minimum of human interaction. This report details an internship in Cynapsys in period of six months.

Otherwise the objective of the internship is to obtain the engineering diploma in the field of IT. Moreover, this project aims to develop a Microsoft

Dynamics Ax solution to manage the maintenance process inside medium-sized enterprises. This module provides the possibility to exploit

technical data, manage the request and work orders, and planning interventions. We used the DBMS SQL server 2014 and SharePoint and the

IDE MorphX, and X++ as a programming language. Throughout this work, we used the Scrum framework to manage the life cycle of the project.

Key word: Microsoft Dynamics Ax, CMMS, EAM, schedule, Scrum, X++, MorphX, SQL Server 20

Adresse Cynapsys

BP 105 Pôle Elgazala des technologies de communication Ariana, 2088

Tél. :71 857 899

info@cynapsys.de

Adresse SESAME

ZI Chotrana I BP4 Pôle Elgazala des technologies de communication, Ariana 2088

Tél. :70 686 486

sesame@sesame.com.tn

Rawdha Mabrouki

14