Download - Rapport PFE ingénieur 2016 PDF
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
Adresse SESAME
ZI Chotrana I BP4 Pôle Elgazala des technologies de communication, Ariana 2088
Tél. :70 686 486
Rawdha Mabrouki
14