Rapport PFE ingénieur 2016 PDF

884 vues

Publié le

Gestion de maintenance assistée par ordinateur autour de l'ERP Dynamics Ax

Publié dans : Formation
0 commentaire
3 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
884
Sur SlideShare
0
Issues des intégrations
0
Intégrations
0
Actions
Partages
0
Téléchargements
72
Commentaires
0
J’aime
3
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Rapport PFE ingénieur 2016 PDF

  1. 1. 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
  2. 2. 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
  3. 3. Rawdha Mabrouki
  4. 4. Rawdha Mabrouki Encadrant Cynapsys Encadrant SESAME Signature Cachet Signature
  5. 5. 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
  6. 6. 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
  7. 7. 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
  8. 8. 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
  9. 9. 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
  10. 10. 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
  11. 11. 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
  12. 12. 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
  13. 13. 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
  14. 14. 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
  15. 15. 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,
  16. 16. 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,
  17. 17. 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 :
  18. 18. 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.
  19. 19. 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é 1 Voir glossaire 2 Voir glossaire
  20. 20. 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 4 Voir glossaire. 5 Voir glossaire. 6 Voir glossaire Figure I-1 : Pôles de Cynapsys [W1]
  21. 21. 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]
  22. 22. 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.
  23. 23. 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]
  24. 24. 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]
  25. 25. 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)
  26. 26. 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. TaskName Duration définitionduprojet 15days MontéeencompétencesurAxapta 8days DocumentationsurAxapta 1day familiaisationavec SCRUM 1day Documentationsurles GMAO 4days rédactionduchapitre1et2 1day élaborationducahier des charge 20days? étudedel'existant 9days élaborationduproductbacklog 2days? Elicitationdes exigences 6days? Planificationdes itérations 1day? Sprint0étudetechniqueAxapta 2days rédactionduchapitre2et3 3days? étude et réalisationduSprint 1 14days? élaborationduSprintBacklog1 2days spécificationdes exigences 2days conception 5days développement 5days ValidationetrédactionduSprint1 1day? étude et réalisationduSprint 2 32days? élaborationduSprintBacklog2 3days spécificationdes exigences 5days conception 15days? développment 8days validationetrédactionduSprint2 1day? étude et réalisationduSprint 3 17days? étude et réalisationduSprint 4 23days? 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 30 February 2016 March2016 April2016 May 2016 June2016 July 2016 August2016 Figure I-6: Diagramme de Gantt prévisionnel
  27. 27. 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
  28. 28. 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
  29. 29. 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 ». 8 Voir glossaire
  30. 30. 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)
  31. 31. 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)
  32. 32. 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
  33. 33. 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.
  34. 34. 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.
  35. 35. 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
  36. 36. 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.
  37. 37. 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
  38. 38. 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
  39. 39. 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
  40. 40. 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)
  41. 41. 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) .
  42. 42. 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. 13 Voir glossaire Figure II-8 : Tableau de bord d’Oracle eAM (solution, 2015)
  43. 43. 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]
  44. 44. 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.
  45. 45. 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
  46. 46. 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
  47. 47. 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).
  48. 48. 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 15 Voir glossaire Figure III-3 : Diagramme de contexte statique
  49. 49. 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.
  50. 50. 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
  51. 51. 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é BrouillonImprimer 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
  52. 52. 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)
  53. 53. 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.
  54. 54. 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)
  55. 55. 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

×