• Save
Opentms
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

Opentms

  • 4,117 views
Uploaded on

Travail de fin d'étude sur le développement d'un module métier dédié au TRANSPORT ...

Travail de fin d'étude sur le développement d'un module métier dédié au TRANSPORT
sur base du framework openobject de openerp

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
4,117
On Slideshare
4,061
From Embeds
56
Number of Embeds
3

Actions

Shares
Downloads
36
Comments
0
Likes
4

Embeds 56

http://www.linkedin.com 37
http://www.slashdocs.com 10
https://www.linkedin.com 9

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Ecole Nationale Supérieure d’Informatique et d’Analyse des Systèmes Mémoire de Projet de Fin d’Études Pour l’Obtention du Titre D’Ingénieur d’État en Informatique Option Ingénierie de la logistique Sujet Etude de benchmarking des solutions TMS, amélioration et extension de la solution OpenTMS. Soutenu par : Sous la direction de : M. Saad THAIFA FATHI M. Abdellatif EL AFIA (ENSIAS) M. Soufiane EL YOUBI M. Abderahman EL KAFIL (SYSTEMUM) Année Universitaire 2010-2011
  • 2. DédicacesA nos très chers parents, Aucun mot ne pourra exprimer notre amour envers eux.A nos frères et nos sœurs, Nous vous remercions pour votre amour inconditionnel.A tous nos collègues de l’ENSIAS, Merci pour ces trois années inoubliables.Pour tout le soutien que vous nous avez offert, vous occuperez pour toujours une partie de nos cœurs. Soufiane EL YOUBI Saad THAIFA FATHIProjet de Fin d‟études 2010-2011 iii
  • 3. Remerciements Il nous est agréable de nous acquitter d‟une dette de reconnaissance auprès de toutesles personnes, dont l‟intervention au cours de ce projet, a favorisé son aboutissement. Nos remerciements les plus sincères vont à M. EL AFIA, notre encadrant à l‟ENSIAS,pour les conseils qu‟il nous a prodigués, son judicieux encadrement ainsi que son assistancepour la rédaction du rapport. Ainsi, nous exprimons notre profonde gratitude et tenons à remercier tout le personnelde la société Systemum pour leur soutien et pour leur générosité considérable quant à l‟offrede l‟information. Nous tenons à exprimer nos gratitudes à M.EL KAFIL, notre encadrant à l‟organismed‟accueil qui nous a proposé un sujet très intéressant et d‟actualités. Que les membres de jury trouvent ici l‟expression de nos reconnaissances pour avoiraccepté de juger notre travail. Que tous ceux et celles qui ont contribué de près ou de loin àl‟accomplissement de ce travail trouvent l‟expression de nos remerciements les pluschaleureux.Projet de Fin d‟études 2010-2011 iv
  • 4. RésuméLe présent rapport se situe dans le cadre du projet de fin d‟études pour l‟obtention du diplômed‟Ingénieur d‟État en Génie Informatique de l‟Ecole Nationale Supérieure d‟Informatique etd‟Analyse des Systèmes (ENSIAS). Ce projet a pour objectif d‟améliorer et d‟étendre unsystème de gestion de transport.Pour établir un plan d‟action, nous avons eu recours à une étude préliminaire qui comporte àla fois un benchmarking et un diagnostic du système existant, afin de cerner les failles et lesproblèmes qui ont un impact déprécié sur la qualité du progiciel.Pour bien mener notre projet, nous avons adopté une des méthodes agiles, à savoir XP(eXtreme Programming), démarche qui a fait ses preuves dans le domaine des projetsinformatiques et qui est plus adaptée aux équipes réduites avec des besoins changeants.Après une analyse approfondie, nous avons décidé de découper notre travail en deux parties :un paramétrage et un développement spécifique. Pour les modules « Portail » et « Tracking »,une analyse et une conception conformes aux règles de gestion ont été élaborés et décritesavec le formalisme UML. Tandis que le module GMAO a été modélisé avec la méthodeARIS.Quant à la phase de réalisation, elle a été faite en se basant sur le progiciel libre OpenERP, quiest couplé à une base de données PostgreSQL. Par ailleurs, la localisation GPS de la flotte estréalisée en se basant sur l‟outil OpenGTS.Mots-clés: Systemum, UML, ARIS, GMAO, XP, ERP, OpenERP.Projet de Fin d‟études 2010-2011 5
  • 5. AbstractThe current report is a part of the final year project to get the diploma of chartered engineer incomputer science engineering of Informatics & Systems Analysis National School (ENSIAS).The aim of this project is to improve and expand a Transport Management System.To establish an action plan, we used a preliminary study that contains at the same time abenchmarking study, and a diagnosis of the existing system, to identify flaws and problemsthat have a deprecated impact on the quality of the software.To properly conduct our project, we adopted an agile method, XP (eXtreme Programming),an approach that is used in the field of IT projects, and that is more adapted by small teamswith changing needs.After a thorough analysis, we decided to divide our work into two parts : Customization andspecific programming.Regarding the « Portal » and « Tracking » modules, an analysis and design, complying withmanagement rules were developed and described following the UML formalism, but themodule « GMAO » was designed with the ARIS method.The implementation stage was made, based on the free software OpenERP, with aPostgreSQL database. GPS tracking of the fleet is carried out based on tool OpenGTS.Key words: Systemum, UML, ARIS, GMAO, XP, ERP, OpenERP.Projet de Fin d‟études 2010-2011 6
  • 6. Liste des abréviations Abréviation Désignation CRM Customer Relationship Management DI Demande d‟intervention DSI Direction des systèmes d‟information ERP Entreprise Ressource Planning GMAO Gestion de maintenance assistée par ordinateur GPRS General Packet Radio Service GPS Global Positioning System GSI Gestion des systèmes d‟informations GSM Global System for Mobile Communications ORM Object Relationnel Mapping PIB Produit intérieur brut PME Petite et moyenne entreprise QT Quality Transport SCM Supply Chain Management SCOR Supply Chain Operations Reference Model SGT Système de gestion de transport SI Système d‟information SIM Subscriber Identity Module TCP Transmission Control Protocol TMS Transport Management System UDP User Datagram Protocol UML Unified Modeling Language XML Extensible Markup LanguageProjet de Fin d‟études 2010-2011 7
  • 7. Table des figuresFigure I-1 : Déploiements reussis de Systemum .................................................................... 17Figure I-2 : Diagramme de GANT ........................................................................................ 20Figure I-3 : L‟eXtreme Programming ................................................................................... 22Figure II-1 : l‟équilibre coût, qualité et délai ......................................................................... 25Figure II-2 : Modèle du processus de gestion du transport..................................................... 26Figure II-3 : Modèle SCOR pour le cas de Transmel/QT ...................................................... 29Figure II-4 : Modules dOpenTMS ........................................................................................ 31Figure II-5 : Ancienne interface pour définir une destination ................................................ 32Figure III-1 : Nouvelles propriétés du trajet ..........................................................................36Figure III-2 : Procédure de la création d‟une liste de prix ...................................................... 37Figure III-3 : Transmission des données GPS sur un réseau GPRS / Mobile ......................... 38Figure III-4 : Diagramme de cas d‟utilisation du module Tracking........................................ 39Figure III-5 : Diagramme de cas d‟utilisation du module Portail TMS .................................. 42Figure III-6 : Diagramme de packages .................................................................................. 43Figure III-7 : Diagramme de classe du module Tracking ....................................................... 44Figure III-8 : Diagramme de classes du module Poratail TMS .............................................. 45Figure III-9 : Diagramme d‟activité du module Portail .......................................................... 46Figure III-10 : Modélisation ARIS de la gestion de la maintenance corrective ...................... 48Figure III-11 : Modélisation ARIS de la gestion de la maintenance préventive...................... 49Figure IV-1 : Architecture modulaire d‟open ERP ................................................................ 52Figure IV-2 : Architecture Client-Serveur d‟OpenERP ......................................................... 52Figure IV-3 : Architecture dun module dOpenERP ............................................................. 53Figure IV-4 : Liste des trajets ............................................................................................... 55Figure IV-5 : Création des variantes du trajet ........................................................................ 56Figure IV-6 : Ligne de commande ........................................................................................ 57Figure IV-7 : Liste des prix ................................................................................................... 58Figure IV-8: Menu du module Tracking ............................................................................... 59Figure IV-9: Formulaire dajout dune balise GPS ................................................................. 59Figure IV-10: Interface daffectation des balises GPS aux véhicules ..................................... 60Figure IV-11 : Contrôle sur les balises déjà affectées ............................................................ 60Figure IV-12 : Onglet de Tracking se trouvant dans la fiche véhicule ................................... 61Figure IV-13 : Tracking par OpenGTS (Sattelite) ................................................................. 62Projet de Fin d‟études 2010-2011 8
  • 8. Figure IV-14 : Tracking par OpenGTS (Plan) ....................................................................... 62Figure IV-15 : Rapport d‟évènements ................................................................................... 63Figure IV-16 : Création dun client........................................................................................ 64Figure IV-17 : Page d‟authentification .................................................................................. 64Figure IV-18 : linterface client ............................................................................................. 65Figure IV-19 : Planification dun voyage par le client ........................................................... 65Figure IV-20 : Ajout des palettes à transporter ......................................................................66Figure IV-21 : Affectation des véhicules aux voyages .......................................................... 66Figure IV-22 : Ajout des palettes de retour ...........................................................................67Projet de Fin d‟études 2010-2011 9
  • 9. Liste des tableauxTableau II-1 : Processus du modèle SCOR...........................................................................29Tableau II-2 : Décomposition du projet en modules .............................................................. 33Tableau III-1: Cas d‟utilisation «Gestion des balises GPS» ................................................... 40Tableau III-2: Cas d‟utilisation «Affectation des balises GPS aux véhicules» ....................... 40Tableau III-3: Cas dutilisation « Tracker un véhicule, Générer le rapport des événements » . 41Tableau III-4: Liste des classes du module « Tracking » ....................................................... 43Tableau III-5 : Liste des classes du module « Portail TMS » ................................................. 45Projet de Fin d‟études 2010-2011 10
  • 10. Table des matièresListe des abréviations ...........................................................................................................7Table des figures ...................................................................................................................8Liste des tableaux ............................................................................................................... 10Table des matières .............................................................................................................. 11Introduction générale ......................................................................................................... 13Chapitre I: Contexte général du projet .............................................................................15I. Contexte général du projet ......................................................................................... 16 I.1 Présentation de Systemum ........................................................................................... 16 I.1.1 Prestations et services ........................................................................................ 16 I.1.2 Secteurs d‟activités ............................................................................................ 17 I.1.3 Quelques références .......................................................................................... 17 I.2 Contexte du projet ....................................................................................................... 18 I.2.1 Problématique ....................................................................................................... 18 I.2.2 Objectifs du projet ................................................................................................ 18 I.2.3 Conduite du projet ................................................................................................ 19 a. Périmètre du projet .................................................................................................... 19 b. Planification du Projet ............................................................................................... 19 I.2.4 Processus de développement ................................................................................. 21Chapitre II: Etude préliminaire des solutions TMS.......................................................... 23II. Etude préliminaire ......................................................................................................24 II.1 Qu‟est-ce qu‟un TMS ? .............................................................................................. 24 II.2 Pourquoi mettre en place un TMS ? ............................................................................ 24 II.3 Processus général de transport .................................................................................... 26 II.4 Analyse des flux : Modèle SCOR ............................................................................... 28 II.5 Description de l‟existant ............................................................................................. 30 II.5.1 L‟existant ............................................................................................................ 30 II.5.2 Critique de l‟existant ........................................................................................... 31 II.6 Synthèse de l‟étude préliminaire ................................................................................. 32Chapitre III : Analyse et conception .................................................................................. 34III. Analyse et conception ................................................................................................. 35 III.1 Paramétrage du module de la gestion des voyages ..................................................... 35 III.1.1 Analyse .............................................................................................................. 35 III.1.2 Paramétrage ....................................................................................................... 35 III.2 Analyse et conception des modules Tracking et Portail TMS .................................... 37 III.2.1 Préambule: Gestion de Flotte de Véhicules ......................................................... 37 III.2.2 Choix du formalisme UML ................................................................................ 38 III.2.3 Diagrammes UML ............................................................................................. 39Projet de Fin d‟études 2010-2011 11
  • 11. III.3 Etude fonctionnelle du module GMAO ..................................................................... 46Chapitre IV: Etude technique et réalisation du projet ..................................................... 50IV. Etude technique et réalisation du projet .................................................................... 51 IV.1 Etude technique ........................................................................................................ 51 IV.1.1 OpenERP ...........................................................................................................51 a. Description d‟OpenERP ............................................................................................ 51 b. Architecture modulaire d‟OpenERP ..........................................................................51 c. Architecture d‟OpenERP ........................................................................................... 52 d. Le Framework de développement OpenObject .......................................................... 53 IV.1.2 Le langage Python.............................................................................................. 54 IV.1.3 PostgreSQL........................................................................................................ 54 IV.2 Interfaces graphiques ................................................................................................ 54 IV.3.1 Paramétrage du module gestion de voyage ......................................................... 54 IV.3.2 Module tracking ................................................................................................. 59 IV.3.3 Module Portail TMS .......................................................................................... 64Conclusion et perspectives ................................................................................................. 68Bibliographie ...................................................................................................................... 69Annexe 1 – L‟Open Source................................................................................................... 72Annexe 3 - Partie du livre blanc TMS ................................................................................... 76Annexe 4 - UML ................................................................................................................. 88Projet de Fin d‟études 2010-2011 12
  • 12. Introduction généraleLe transport est un maillon stratégique dans la chaîne logistique. Ce segment est l‟un despostes de coûts les plus importants qui influe sur la chaîne logistique globale. Les pratiques etles principes de la logistique exigent du transport des évolutions continues pour mieuxrépondre à la demande des entreprises.En effet, les coûts logistiques totaux du Maroc s‟élèvent à environ 20 % du PIB. Ce ratio estsupérieur à celui des pays de l‟Union européenne y compris ceux qui l‟ont rejoint en2004, dont le ratio se situe entre 10 et 16 %, selon une étude de la Banque mondiale sur laperformance de la logistique du commerce au Maroc. [HAIMOUD, 2009]Les coûts de transport représentent une part importante, en moyenne 50 %, des coûtslogistiques sachant que la hausse du prix du carburant, les contraintes règlementaires accrues,et l‟émergence du développement durable sont autant de facteurs inflationnistes à moyenterme.C‟est dans ce souci que Systemum, lieu de notre stage de fin d‟étude, a tenu à élaborer unoutil de gestion de transport intégré, dédié aux transporteurs marocains, et basé sur unsystèmes ERP (Entreprise Ressource Planning) libre, répondant parfaitement à cetteproblématique, puisque l‟enjeu d‟une telle solution est d‟aider ces derniers à maitriser leurscoûts, en gardant une visibilité globale sur l‟ensemble de leurs activités.Notre intervention au sein de Systemum s‟articulait principalement sur la qualification del‟existant, en reconcevant les processus de disfonctionnement d‟une part, et en l‟enrichissantpar des nouveaux modules qui s‟avèrent nécessaire pour couvrir la majorité des besoins dessociétés d‟autre part.Pour mener à bien ces investigations, nous avons établi un livre blanc qui regroupe unensemble de connaissances sur les TMS, ainsi qu‟un benchmarking des principaux systèmesde gestion de transport, dans un souci de situer notre système par rapport aux autres solutions.Notre projet a finalement été couronné, en premier lieu par la réalisation d‟un système desuivi des véhicules basé sur un serveur de géolocalisation, ainsi qu‟un portail intégré pour lesclients des transporteurs; et en second lieu, par l‟analyse et la modélisation du module de lagestion de maintenance assistée par ordinateurs.Le présent rapport décrit en détails notre projet de fin d‟études. Il comporte quatre chapitres :  Le premier concerne le contexte général du projet, en commençant par une présentation de l‟organisme d‟accueil, de la problématique traitée et les objectifs visés, suivis de la conduite adoptée pour le déroulement du stage.  Le deuxième chapitre trace le périmètre des systèmes de gestion de transport à la lumière de l‟étude de l‟existant.  Le troisième chapitre présente l‟analyse et la conception des solutions apportées, sous forme de diagrammes UML et ARIS.Projet de Fin d‟études 2010-2011 13
  • 13.  Le quatrième chapitre sintéresse à la partie mise en œuvre du système, il illustre les différentes réalisations et les technologies utilisées. A la fin du rapport, nous présenterons en complément les différentes annexes traitant laliste des références ainsi que d‟autres informations nécessaires à la bonne compréhension denotre projet.Projet de Fin d‟études 2010-2011 14
  • 14. Chapitre 1 Contexte général du projetChapitre I Contexte général du projet Dans ce premier chapitre nous présenterons l’organisme d’accueil, le cadre général du projet, ses objectifs, ainsi que la conduite du travail adoptée pour ce projet.Projet de Fin d‟études 2010-2011 15
  • 15. Chapitre 1 Contexte général du projet I. Contexte général du projet I.1 Présentation de SystemumSystemum est une Société de Services en Logiciels Libres (SSLL) qui accompagne lesentreprises et institutions dans le choix des solutions open source ainsi que dans lintégration,le développement, ladaptation aux besoins spécifiques, la maintenance et le support. Afin debénéficier des meilleures solutions libres dans la gestion des systèmes dinformation.Systemum a développé une expertise autour d‟OpenERP depuis 2006 (premier partenaireofficiel OpenERP au Maroc en 2007) et a contribué à faire connaître cet ERP open source auMaroc à travers plusieurs déploiements réussis dans les PME marocaines et des conférencesdans les universités et adapte celui-ci à la législation marocaine et aux besoins spécifiquesdes entreprises. I.1.1 Prestations et servicesSystemum offre une large palette de prestations et de services basés sur des composants libresadaptés aux systèmes et aux réseaux des clients. La principale tâche de cette société estd‟offrir des solutions sur mesure, en matière de formation et d‟assistance, concernant lesproblématiques relevant des systèmes d‟informations, moyennant des outils libres.La gamme de services de Systemum est articulée autour de quatre axes majeurs quipermettent daccompagner les clients durant toutes les phases dun projet afin den assurer saréussite en :  Formation : L‟offre des formations, techniques et fonctionnelles, permet daccompagner les organisations qui disposent d‟équipes opérationnelles capables de mener à bien des projets. Ces formations peuvent être établies sous forme de transferts de compétences, en phases avals des projets.  Support : En plus des offres de formations, la société propose aux équipes dédiées au développement, des prestations de support d‟aide à la maintenance, afin de réduire le temps de résolution des interrogations ou des difficultés que les entreprises pourraient rencontrer lors de la mise en œuvre de certains logiciels.  Conseil : Systemum possède une équipe formée de consultants techniques et fonctionnels qui assure soit dans le cadre de projets, soit en amont, des missions de conseil dans les domaines suivants: gestion de contenu, travail collaboratif, dématérialisation des procédures, migration vers le libre, architecture et dimensionnement dapplications basées sur OpenERP…etc.  Développement : Il constitue le cœur métier de Systemum et comprend le développement sur la base de logiciels libres, de portails collaboratifs internet ou intranet, avec des composantes de publication web, de travail collaboratif, de gestion électronique de documents et de workflow.Projet de Fin d‟études 2010-2011 16
  • 16. Chapitre 1 Contexte général du projetI.1.2 Secteurs d’activitésDe par les multiples projets que Systemum a mené, elle a acquis un savoir-fairesusceptible de lui permettre l‟implantation de logiciels libres dans les différents secteurs:  Enterprise Ressource Planning (ERP) : En français Progiciels de Gestion Intégré (PGI).  Customer Relationship Management (CRM) : Systemum propose l‟offre SUGARCRM qui permet la gestion de la relation client.  Intranet des entreprises et gestion des contenus : Création d‟identités visuelles et sites internet institutionnels et e-Commerce. La solution proposée est Vertumart qui est une solution libre de e-commerce(Commerce électronique) qui sappuie sur le gestionnaire contenu Joomla.  Gestion électronique des documents : Il s‟agit d‟un système informatisé dacquisition, classement, stockage et archivage des documents. La solution proposée est Alfresco. I.1.3 Quelques référencesSystemum compte plusieurs déploiements réussît d‟OpenERP dans des PME marocaines dontje cite quelques références : Figure I-1 : Déploiements reussis de SystemumProjet de Fin d‟études 2010-2011 17
  • 17. Chapitre 1 Contexte général du projet I.2 Contexte du projet I.2.1 ProblématiqueTous les praticiens et logisticiens s‟accordent à affirmer qu‟une logistique performante estcapable de booster la compétitivité de l‟économie marocaine. Ceci ne peut se réaliser sans lamaîtrise des coûts de transport, qui restent les plus élevés parmi les autres coûts de la chaînelogistique. Tout en sachant que le mode routier assure trois quarts des flux de marchandises.C‟est ce qui a poussé les transporteurs marocains à s‟intéresser aux systèmes de gestion detransport pour essayer de maitriser et réduire ces coûts élevés de transport.Toutefois, et en raison de leurs complexités et leurs coûts de licences élevés, les transporteursmarocains, incapables d‟acquérir des systèmes de gestion de transport comme celui de Sageou SAP (3 000 000 Dh), se contentent des applications modestes et réparties souventdéveloppées en interne.Systemum a compris l‟enjeu, et réagi ainsi, en faveur de ces entreprises en s‟investissant pourmettre en œuvre une solution économique qui répond parfaitement aux besoins desprestataires nationaux, tout en bénéficiant de l‟expertise de la société dans les systèmesd‟informations Open Source grâce au logiciels libres qui ont permis de diminuer les coûts dedéveloppement. I.2.2 Objectifs du projetC‟est dans ce sens qu‟on se fut accueilli au sein de Systemum pour attribuer à ce projet, qui seveut être une solution Open Source satisfaisant plusieurs fonctionnalités, nécessaires pourchaque prestataire de service de transport et dont on cite : - Assurer la saisie des commandes et des ordres de transport. - Gérer efficacement la comptabilité, la paie et la commission des chauffeurs. - Fournir les indicateurs clés nécessaires pour prendre les bonnes décisions. - Permettre la maitrise des ressources, en assurant un suivi de l‟état et des positions des véhicules du parc.Notre mission au sein de la société était tout d‟abord, de faire une étude sur les différentessolutions TMS disponibles sur le marché, pour examiner les nouvelles fonctionnalités àintroduire dans notre solution, dans le but de s‟aligner avec les nécessités croissantes destransporteurs marocains. Ensuite, il fallait mettre en cause l‟existant, examiner ses interactionsavec les modules de bases d‟OpenERP et détecter ainsi ses anomalies afin de les corriger.Une fois le périmètre de notre intervention est précisé, c‟est à nous alors de passer en actionsen concevant, développant et intégrant ces nouveautés dans l‟OpenTMS.Projet de Fin d‟études 2010-2011 18
  • 18. Chapitre 1 Contexte général du projet I.2.3 Conduite du projet a. Périmètre du projetDurée de stage : 3 mois et 15 jours.Les ressources affectées à ce projet:  Chef de projet: Abderrahmane ELKAFIL.  Consultant fonctionnel: Rachid IBIZI  Consultant technique: AbdelFettah SGHIOUAR.  Ingénieur étude et développement : Soufiane EL YOUBI et Saad THAIFA FATHILes livrables :  Livre blanc TMS  Rapport Etude de l’ancien module.  Rapport technique.  Rapport de stage. b. Planification du ProjetLa planification du projet fait partie des phases davant-projet. Elle consiste à prévoir ledéroulement des tâches tout au long des phases constituant le cycle de développement. Grâceaux réunions tenues avec l‟encadrant interne, nous avons été éclairés sur les différentes étapesdu projet ainsi que sur les modalités de leurs déroulement.La figure suivante présente le planning prévisionnel du projet selon le diagramme de Gant:Projet de Fin d‟études 2010-2011 19
  • 19. Chapitre 1 Contexte général du projet Figure I-2 : Diagramme de GANTProjet de Fin d‟études 2010-2011 20
  • 20. Chapitre 1 Contexte général du projet I.2.4 Processus de développementDans le cadre de notre projet de développement, il était pour nous difficile d‟appliquer uneméthodologie de gestion de projet informatique lourde, telle que celles proposées par lesmodèles de gestion usuelle. Cependant, nous devrions nous munir d‟une démarcheméthodologique pour mener à bien l‟ensemble des tâches du projet. Pour cela, nous avonsopté pour le choix de la méthode agile Extreme Programming(XP), d‟une part en raison de sesperformances et d‟autre part pour assurer son processus qualité. a. Méthodes agilesLes méthodes Agiles sont des groupes de pratiques pouvant sappliquer à divers types deprojets, mais se limitant plutôt actuellement aux projets de développement en informatique(conception de logiciel). Les méthodes Agiles se veulent plus pragmatiques que les méthodestraditionnelles. Elles impliquent au maximum le demandeur (client) et permettent une granderéactivité à ses demandes. Elles visent la satisfaction réelle du besoin du client et non lestermes dun contrat de développement. La notion de méthode agile a été officialisée en 2001par un document, le Manifeste Agile (Agile Manifesto), signé par 17 personnalités impliquéesdans lévolution du génie logiciel, en particulier, en tant quauteur de leur propre méthode. b. La méthode XPFaisant partie des méthodes agiles, XP vise à réduire le cycle de vie du logiciel, tout enaccélérant son développement par la mise en place d‟une version minimale. Cette version estensuite enrichie itérativement, à chaque fois que de nouvelles fonctionnalités apparaissent.La méthode XP fournit aussi des pratiques permettant de développer dans des conditionsoptimales. Elle est basée sur les principes suivants :  Le cycle de travail est court  Les livraisons des versions sont à une fréquence élevée  L‟équipe de développement travaille sur la base de binômes  Le développement est divisé en itérations de livraison  L‟itération de livraison se décompose en quatre phases : phase d‟exploration, phase d‟engagement, phase de pilotage et phase de livraison. Pour plus de clarté, la démarche XP est présentée sur la figure suivante.Projet de Fin d‟études 2010-2011 21
  • 21. Chapitre 1 Contexte général du projet Figure I-3 : L’eXtreme ProgrammingLe cycle se répète tant que le client peut fournir des scénarios à livrer. Généralement le cyclede la première livraison se caractérise par sa durée et le volume important de fonctionnalitésembarquées. Après la première mise en production, les itérations peuvent devenir pluscourtes.ConclusionLe contexte général étant défini, il convient de comprendre les enjeux d‟un système transportet d‟étudier les différents besoins des utilisateurs avant d‟aboutir à la conception du systèmeescompté. Le second chapitre traitera en détails les spécifications des TMS.Projet de Fin d‟études 2010-2011 22
  • 22. Chapitre 2 Etude préliminaireChapitre II Etude préliminaire des solutions TMS Ce chapitre comporte une étude préliminaire dans laquelle nous essayerons dégager les principales fonctionnalités utiles à la mise en place de notre projet à l’aide de la modélisation SCOR et d’un benchmarking effectué à cet égard.Projet de Fin d‟études 2010-2011 23
  • 23. Chapitre 2 Etude préliminaireII. Etude préliminaireLe transport dispose aujourdhui de son système dinformation que lon nomme, en bonanglais, TMS (Transport Management System). Mais ce marché est relativement jeune etdemande encore à se structurer.Dans ce chapitre on va essayer de bien cerner ce sujet, préciser les enjeux qui l‟entourent, etdégager les différentes fonctionnalités d‟un bon TMS. II.1 Qu’est-ce qu’un TMS ?Le TMS (Transport Management System) ou en français SGT (Système de Gestion destransports) selon le GSI, est avant tout un sous ensemble fonctionnel de la « Supply ChainExecution ».Un TMS est donc un outil d‟optimisation lié aux transports dans leur globalité, qu‟il soitacheté auprès des transporteurs, ou produits avec des moyens en propre. Cette applicationinformatique qui couvre toutes les activités liées à la gestion des transports: depuis la gestiondes données de base et l‟installation des offres, jusquà la facturation des clients et des sous-traitants, en passant par la gestion des ordres de transport et leur dispatching.Parmi les fonctions principales que peut offrir un TMS on peut citer : la gestion des offresaussi bien des fournisseurs que celles des clients, l‟aperçu des transports prévus et desvéhicules disponibles, la facturation du fret et des prestations de service, la gestion desdifférents documents de transport et des véhicules ainsi que des assurances, le suivi du parcautomobile, l‟entrée des ordres de transport, et l‟intégration ou l‟implémentation avec desapplications de comptabilité et de gestion des documents..Plusieurs variantes étendues de TMS sont utilisables via internet. Celles-ci permettent auxclients d‟une part, de saisir et suivre directement leurs expéditions, aussi, ils peuvent imprimerles bons de livraison. Et aux destinataires d‟autre part d‟avoir accès à la liste de leursexpéditions, pour suivre et s‟informer de la date prévue de livraison. Ils permettent aux sous-traitants qu‟ils soient transporteurs ou correspondant de renseigner le système TMS des dateset heures de livraison et de problèmes particuliers relatifs aux expéditions. II.2 Pourquoi mettre en place un TMS ?Tout d‟abord, la mise en place d‟un TMS équipe les entreprises d‟un outil performant pourconnaître et réduire les coûts de leurs transports tout en garantissant l‟équilibre des troiséléments fondamentaux que sont le coût, la qualité et le délai. Les entreprises ayant un coût detransport élevé auront donc un intérêt particulier à mettre en place une telle solution. Sansnégliger l‟intérêt environnemental pour les entreprises qui souhaitent réduire leur empreintecarbone.Projet de Fin d‟études 2010-2011 24
  • 24. Chapitre 2 Etude préliminaire Figure II-1 : l’équilibre coût, qualité et délaiLa mise en œuvre d‟un TMS ne se limite pas à une liste de coûts : il est nécessaire de calculerle retour sur investissement du projet pour convaincre les instances de décision de l‟entreprisede l‟intérêt de cette démarche. Au-delà des aspects purement financiers, il est important deprendre en considération l‟ensemble des gains qualitatifs associés à la mise en œuvre d‟unTMS au sein de l‟entreprise. En effet, le système de gestion du transport a un impact positifsur différents éléments, il permet aux entreprises de : - Maîtriser l‟information du processus Transport : La maîtrise de linformation est devenue désormais un enjeu stratégique pour les entreprises qui veulent gagner, combattre efficacement la concurrence ou même simplement se maintenir, dans un monde qui bouge vite, où ladaptation et linnovation sont le socle de la survie. Cependant, Cet atout permet d‟intégrer de façon simple toutes les contraintes opérationnelles, de synchroniser les activités de transports avec l‟entrepôt, de tracer les marchandises et enfin de disposer d‟un véritable outil d‟aide à la décision. - Gérer au mieux le transport au niveau opérationnel : Cet avantage inclut la saturation des moyens de transport pour un remplissage optimal de la capacité tonnage des véhicules, le regroupage des commandes, l‟amélioration du service clientèle, la réduction des délais des livraisons, la réduction du nombre de litiges…etc. Ce qui se traduit par une réduction globale des achats de transport - Améliorer le service client : Tout en réduisant les délais des livraisons, suivant l‟état des expéditions et diminuant le nombre des litiges, ce qui est un facteur de satisfaction et de confiance dans la prestation et véhicule une bonne image auprès des clients. - Réduire les coûts associés : Compte tenu des hausses des prix du pétrole et de l‟énergie, le transport représente sans aucun doute un levier d‟action important pour réaliser des économies. Cependant, la réduction des coûts associés du transport passe par la réduction des coûts administratifs et de la facture transport.Projet de Fin d‟études 2010-2011 25
  • 25. Chapitre 2 Etude préliminaireLe TMS amène indéniablement des progrès qualitatifs et quantitatifs au sein de l‟entreprise.Dans un contexte où « le client est roi », l‟intégrité et la véracité des informations qui sontcommuniquées sont un facteur essentiel de réussite. En effet, ces informations vont fortementaider les décisionnaires dans leurs choix qui doivent être résolu dans des délais de plus en plusbrefs. Cette information qualitativement pertinente sera immédiatement accessible auxdifférents niveaux décisionnels : stratégique, tactique, opérationnel, exécution et suivi.[NDIAYE et al, 2011] II.3 Processus général de transportAvant de décrire et juger l‟existant, il est nécessaire d‟être clair sur le périmètre fonctionnelcouvert par ce type de progiciel. Nous présentons alors un modèle du processus de gestion dutransport qu‟il est recommandé de suivre dans le but d‟élaborer et d‟optimiser les plansstratégiques, tactiques et opérationnels, pour une rentabilité et une qualité de serviceaméliorées. Ce processus général du transport commence de l‟étape de réception decommande, planification et choix des tournées jusqu‟à la facturation en passant par les étapesde sélections de transporteurs et de préparation des charges. Réception de l’ordre Préparation de Sélection du des charges transport transporteur de livraison Planifica- Optimisation des tournées tion Facturation de livraison Figure II-2 : Modèle du processus de gestion du transportDonc on peut voir ce processus comme la succession des étapes suivantes :Réception de l’ordre de transportCette étape présente la première réception de la commande ou de l‟ordre de transport par leprestataire logistique, qu‟elle soit par mail, téléphone ou faxe. Cet ordre est enregistré dans leProjet de Fin d‟études 2010-2011 26
  • 26. Chapitre 2 Etude préliminairesystème d‟information de la société et une réponse de confirmation ou de rejet est renvoyer àl‟égard du client.Planification des voyagesIl s‟agit d‟optimiser le partage des ressources pour satisfaire les ordres de transport. Ainsi Lesexpéditions inférieures à un camion complet sont regroupées pour constituer des camionscomplets.Aussi, les horaires d‟enlèvement et les délais de livraison doivent être déterminés de façon àoptimiser l‟utilisation des équipements tout en tenant compte des contraintes du client.Affectation des transporteursUne fois défini le planning de chargement, il s‟agit de préciser comment la charge seratransportée. La première décision à prendre est de savoir si les moyens de transport seront lesmoyens en propre ou s‟ils seront sous-traités. La sous-traitance du mouvement implique unappel d‟offre et une sélection du transporteur. Quand il s‟agit d‟équipements en propre, il estnécessaire d‟affecter les ressources (chauffeurs, véhicules et ressources).Communication des décisions Les décisions d‟affectation doivent être transmises par la suite aux transporteurs et auxchauffeurs concernés. Parfois un accusé de réception est exigé en retour, particulièrementdans le cas de sous-traitance.Optimisation des tournéesL‟optimisation des tournées et du transport se manifeste : - Au niveau stratégique : prendre des décisions en termes d‟investissement et d‟organisation (stratégie de distribution, localisation de dépôts ou entrepôts, optimisation mixte des flottes de véhicules, conception des schémas de distribution). - Au niveau tactique : gérer les saisonnalités, modifier la répartition des clients et de la demande dans le but déquilibrer la charge de travail au fil du temps. - Au niveau opérationnel : comment exécuter un plan tactique en prenant en compte de façon dynamique les aléas quotidiens (circulation, météo, absence, panne de matériel…) ou les arrivées et changements de commandes.Préparation des charges et livraisonsIl s‟agit du processus d‟enregistrement des informations relatives à la préparation, auregroupement et à l‟expédition des charges. Cette information est utilisée pour réagir face àdes évènements anormaux tels que des retards et également pour des informations financières.Projet de Fin d‟études 2010-2011 27
  • 27. Chapitre 2 Etude préliminaireGestion des évènementsLe processus d‟exécution des expéditions est contrôlé. Si un évènement exceptionnelintervient, une action doit être entreprise. Par exemple, si une expédition est en retard ou si unvéhicule est stoppé, une réponse peut être d‟informer le client par e-mail ou de replanifierl‟expédition.FacturationDernière étape dans le processus de transport, la facturation du chargeur (client) est requise. Ilexiste aussi des états financiers à établir en cas de sous-traitance du transport ou d‟appeld‟offre. [NDIAYE et al, 2011] II.4 Analyse des flux : Modèle SCORDans cette partie on analysera les flux nécessaires à la modélisation d‟un système de transportqui maitrise ces différents flux physiques et d‟informations. On introduira donc les bases de laméthode SCOR du Supply Chain Council qui a l‟avantage de présenter un cadre d‟analyseclair, que l‟on va combiner après avec d‟autres méthodes classiques d‟analyse.La méthode SCORLa méthode SCOR (Supply Chain Operations Reference-Model) est une méthode normativede description et d‟évaluation des flux d‟une entreprise dans l‟optique Supply Chain. Elle aété créée en 1996, avec le parrainage de deux sociétés de conseil (PRTM et AMR), par unensemble d‟entreprises nord-américaines rassemblées au sein d‟un organisme : le SCC(Supply Chain Council). L‟objectif était de mettre au point une méthode de description de lalogistique des entreprises et des indicateurs permettant d‟en mesurer l‟efficacité. [YVES et al,2010]Dans notre cas nous avons étudié l‟exemple de l‟entreprise TRANSMAEL / QT, le premierclient à vouloir bénéficier de la solution OpenTMS. Toutefois, les résultats peuvent êtregénéralisés pour toute entreprise de transport.Quatre processus de management constituent le cœur de SCOR et l‟on a préféré conserver iciles termes américains, quitte à les traduire, afin de respecter la présentation du Supply ChainCouncil :– Plan : planifier.– Source : approvisionner depuis un fournisseur interne ou externe.– Make : produire.– Deliver : livrer, et distribuerProjet de Fin d‟études 2010-2011 28
  • 28. Chapitre 2 Etude préliminaireDans le cas d‟un transporteur, ces processus peuvent se résumer et être présenter comme suit :Source Make DeliverS1 :c’est l’approvisionnement M1 : activité de production de D2 : la distribution des besoinsde la société pour le besoin du TRANSMEL = transport de la part des fournisseursparc D3 : la distribution et leS2 : la marchandise qui est transport de la marchandiseune fois arrivée à destinationest approvisionnée chez leclient Tableau II-1 : Processus du modèle SCOR Figure II-3 : Modèle SCOR pour le cas de Transmel/QTProjet de Fin d‟études 2010-2011 29
  • 29. Chapitre 2 Etude préliminaireTransmel est un prestataire de services transport, c‟est-à-dire que son activité (M1) consiste àrecevoir des commandes de marchandises à transporter (D3), ce qui explique D3=M1 (lefournisseur des produits à transporter = client pour lequel on livre la marchandise).Cependant Transmel doit aussi piloter ces activités et c‟est ce qui apparaît sur les flèchessituées au-dessus des précédentes avec le pilotage ou la planification des approvisionnements(Plan = P2), le pilotage ou la planification des voyages et de la distribution (Plan = P3). Lepilotage ou la planification générale de la Supply Chain de Transmel est exprimé par la flècheP1 qui représente le pilotage de P2 et P3.Cependant, un des principes de base de SCOR est que l‟on doit représenter la Supply Chaindepuis les « fournisseurs des fournisseurs » jusqu‟aux « clients des clients ». C‟est ce quiapparaît dans les colonnes « Fournisseurs », « Fournisseurs des fournisseurs », « Clients » et «Clients des clients » avec : D2 pour un fournisseur de besoins du parc de la société (gasoil,pièces d‟échange, camions …etc.). Nous n‟avons pas détaillé ce qui concerne les clients desclients ou les fournisseurs des fournisseurs, puisque notre propre intérêt de cette modélisationreste de capter les flux à gérer dans l‟application et non une maitrise du flux général.Bien entendu, l‟entreprise Transmel n‟a pas la maîtrise de l‟ensemble de sa Supply Chain. Sipar la suite d‟accords de coopération, elle devenait capable de piloter l‟ensemble de la SupplyChain comme une entreprise virtuelle, il conviendra de rajouter un nouveau niveau depilotage de l‟ensemble de la Supply Chain.La méthode peut ne pas rester à ce stade de généralité et chaque processus (représenté par uneflèche sur la figure précédente) doit être décomposé en plusieurs sous-processus.S‟ajoute à ceci l‟étude de benchmarking effectué (voir l‟annexe 2), pour déduire lescontraintes de fonctionnalités et de réalisations suivantes : - Le SI à réaliser doit permettre l‟intervention du client à la planification (P2) des voyages et le suivi de ses commandes jusqu‟à l‟arrivée à la destination. - La partie approvisionnement concernant la maintenance de la flotte nécessite une maitrise et évolution autant au niveau des méthodes de gestion des opérations qu‟au niveau des moyens techniques mises en œuvre pour assurer une disponibilité maximale des équipements et ce, à coût minimum. II.5 Description de l’existant II.5.1 L’existantLa première version de la solution OpenTMS a été développée de façon à couvrir lesprincipales fonctionnalités qui constituent le processus standard de transport.Projet de Fin d‟études 2010-2011 30
  • 30. Chapitre 2 Etude préliminaireAinsi cinq briques de base ont été réalisées en outre des modules de gestion d‟OpenERP quisont :Module Parc Module Parc - Gestion de Parc - Gestion des véhicules (tracteur, Solo, Semi- remorque …) Module - Gestion des chauffeurs Module voyage Commission - Affectation des Semi-remorques - Montage et démontage des pneus OpenTMS - Gestion d’huilesModules Voyage Module Module - Définition des trajets, tarifs et destinations Maintenance planification - Suivi des commandes clients - Contrôle bon carburant Figure II-4 : Modules dOpenTMS - L’activité des chauffeurs - Calcule Tarif voyage en Tonne & kilomètre - Suivi des livraisons client (par voyage, commande, voyage et véhicules) - Impression des bons de commandes &livraisonsModule Planification - Les tournées sont planifiées en utilisant les ressources disponibles - Une vue calendrier (Par mois, semaine, jour) - Une évaluation rapide de l’impact des nouvelles contraintes - Créer des tournéesModule Commission chauffeur - Calcule de la commission des chauffeurs à base des voyages faits. - Edition des bulletins de paie. II.5.2 Critique de l’existantLa partie déjà développée couvre une grande partie du processus de transport, depuis laréception des commandes voyages, passant par leurs planifications et arrivant à leursfacturations aux clients.Toutefois, et après un premier diagnostic, il s‟est avéré nécessaire de revoir le volet de lagestion des commandes voyages d‟une part.Projet de Fin d‟études 2010-2011 31
  • 31. Chapitre 2 Etude préliminairela complexité du métier des transporteurs marocains qui se caractérise par la multiplicité desméthodes de facturation pour des clients différents, des marchandises différentes et des trajetsdifférents, a obligé les concepteur de passer par une entité « Destination » comme un produità servir Figure II-5 : Ancienne interface pour définir une destinationEn effet et comme expliqué sur la figure, une « destination » est composée de l‟ensembletrajet, marchandise et client. Ceci alourdi le serveur vu le nombre important desenregistrements et rend l‟utilisation délicate.D‟autre part, et pour que le produit soit plus complet, il était nécessaire d‟étendre le logicielavec d‟autres modules. II.6 SynthèsePour remédier aux problèmes cités ci-dessus et pour assurer la fluidité du flux du processus detransport comme expliqué par le modèle SCOR, nous avons déterminé les actions àentreprendre:  Corriger les défauts au niveau de la conception du module voyage.  La mise en place d‟une solution de gestion de maintenance.  La mise en place d‟une solution pour le tracking des véhicules.  La réalisation d‟un portail pour le suivi des voyages.Ainsi, nous avons décomposé notre projet en quatre modules :Projet de Fin d‟études 2010-2011 32
  • 32. Chapitre 2 Etude préliminaireModule ObjectifsModule « Voyage » et « planification » Correction de la conceptionModule « Tracking » Tracker en temps réel des véhicules avec l‟outil OpenGTSModule « Portail » Permet aux clients des prestataires de transport de suivre l‟état de leurs voyagesModule « GMAO » Concernant la maintenance assistée par ordinateur Tableau II-2 : Décomposition du projet en modulesConclusionCette étude préliminaire nous a permis de dégager les principales fonctionnalités utiles pour lamise en œuvre de notre projet. Nous entamerons dans le chapitre suivant les phases d‟analyseet de conception.Projet de Fin d‟études 2010-2011 33
  • 33. Chapitre 3 Analyse et conceptionChapitre III Analyse et conceptionLe présent chapitre est consacré à la description de l’aspect fonctionnel à travers une analyse des diagrammes des cas d’utilisations et des diagrammes de classes qui définissent la structure interne de notre système. Nous terminerons ce chapitre par une modélisation ARIS de la gestion de la maintenance.Projet de Fin d‟études 2010-2011 34
  • 34. Chapitre 3 Analyse et conceptionIII. Analyse et conception III.1 Paramétrage du module de la gestion des voyages III.1.1 Analyse Pour les transporteurs plusieurs types de commandes se présentent et sont à traiter: - Commande de voyage en tonne : Où la tarification est calculée à partir de la quantité en unité de tonne livrée, ceci peut inclure aussi un montant fixe de transport. - Commande de voyage en kilomètre : Où on facture le kilométrage parcouru (compteur à l‟arrivée - compteur du départ). - Tournées : Qui peuvent êtres soit en tonne ou en kilomètre ou même en pièces. Donc pour corriger le problème conceptuel cité dans le chapitre précèdent tout en prenant en considération la variance des commandes déjà cités, on a décidé tout d‟abord, de faire hériter chaque trajet du module Produit. Ensuite, d‟installer le module « Produit_Multi_Variant » qui nous a permis de créer plusieurs « Template » pour un même produit. Un produit « Template », a maintenant un ensemble de dimensions (comme la couleur, la taille…). Pour chaque dimension, un produit « Template » a un ensemble de valeurs dimension (comme rouge, vert pour la dimension de couleur). Pour chaque dimension, on peut accepter ou non les valeurs de dimension personnalisée. En d‟autres termes dans notre cas, pour un trajet (Fès- Casa) on peut créer plusieurs variantes (Fès-Casa Tonne, Fès-Casa Kilomètre…). Troisième chose à faire c‟est d‟utiliser les Listes de prix, existants sous OpenERP, qui permettent de gérer les promotions, les prix spéciaux clients, les segmentations des contrats faits par clients/fournisseurs, etc. Cela permet de, soit fixer un prix fixe, ou d‟utiliser des règles de calcul de prix en fonction de divers paramètres tels que le coût, la date, la devise, et la catégorie de produit. Ainsi on associe à chaque variante déjà créée des règles de prix : par exemple pour Fès-Casa Tonne associé à un client1 on précise le tarif à la Tonne, la remise, prix fixe … etc. III.1.2 Paramétrage OpenERP supporte déjà des variantes au niveau de base. Mais sans ce module, les variantes ne sont que mono-axial. OpenERP utilise en effet l‟objet « product.tempate » comme modèle du produit et l‟objet « product.variant » comme des variantes de produits. Grâce à ce module, on peut désormais traiter les variantes multiaxiales facilement. Chaque variante peut avoir un supplément de prix qui sera pris en compte lors du calcul du prix de base énuméré. Projet de Fin d‟études 2010-2011 35
  • 35. Chapitre 3 Analyse et conception Figure III-1 : Nouvelles propriétés du trajetAinsi, la nouvelle configuration va nous donner la possibilité de générer des variantes de trajetà partir d‟un trajet modèle. A titre d‟exemple, à base du trajet „Casablanca – Rabat‟, onobtiendra les variantes : „Casablanca – Rabat *Km‟, „Casablanca – Rabat *Tonne‟,„Casablanca – Rabat *forfait‟.Toutefois, la politique des prix dépend de plusieurs considérations telles le client, lamarchandise transportée, le trajet demandé. D‟où l‟importance d‟utiliser une « liste de prix »par client, en plus de la liste de prix standard pour les prix des produits inchangeables.El général, les « listes de prix », ont permis de gérer les promotions, les prix spéciaux clients,les segmentations des contrats faits par clients ou par fournisseurs. Cela permet de, soit fixerun prix fixe, ou d‟utiliser des règles de calcul de prix en fonction de divers paramètres tels quele coût, la date, la devise et la catégorie de produit.Ainsi la figure ci-dessous illustre la procédure générale de la création d‟une liste de prix :Projet de Fin d‟études 2010-2011 36
  • 36. Chapitre 3 Analyse et conception Figure III-2 : Procédure de la création d‟une liste de prixFinalement, l‟association des variantes des produits avec les listes de prix a résolu lesproblèmes rencontrés au paravent. III.2 Analyse et conception des modules Tracking et Portail TMS III.2.1 Préambule: Gestion de Flotte de VéhiculesEn combinant la technologie GPS avec la couverture GSM sans fil, les compagnies peuventrecueillir de linformation telle que lendroit, les arrêts, la marche en ralenti et le kilométrage,dun véhicule qui peuvent être rapidement analysées pour rapporter des avantages dans lesréductions des coûts defficacité. Avec quelques systèmes, nous pouvons passer en revuelhistorique des véhicules en ligne.Des fonctions spéciales permettent à des expéditeurs de connaitre rapidement quel véhicule estle plus proche dun endroit ou dune borne limite dun client. Ceci offre un meilleurcheminement, des coûts de carburant diminués et dun usage plus efficace des ressources toutcomme le service à la clientèle amélioré par des réponses plus rapides. Les gestionnaires deflotte peuvent identifier et afficher un grand nombre de bornes limites sur une cartographieinternet. Les utilisateurs écrivent simplement ladresse et le nom de lendroit quils voudraientaccentuer. Par cela, ils peuvent voir quel conducteur est le plus proche dun client donné et destemps darrivée plus précis et rapide dexpédition peuvent être alors prévu.Repérage en Temps Réel, réseau cellulaire :C‟est la méthode la plus commune de transmission de données vers un serveur. Le dispositif derepérage par GPS muni dun modem GSM qui utilise généralement une carte SIM fournie parun fournisseur de données sans fil. Le modem utilise ce plan de données pour établir uneconnexion à Internet, puis une connexion socket avec le serveur. Une fois connecté au serveur,il envoie généralement ses informations de localisation, puis se déconnecte. Les donnéespeuvent être transmises via UDP ou TCP. Chacun mode a ses avantages et ses inconvénients,cependant UDP est généralement préféré en raison de son efficacité et sa grande largeur deProjet de Fin d‟études 2010-2011 37
  • 37. Chapitre 3 Analyse et conceptionbande de données. Dans certains cas, les données peuvent être acheminées vers le serveur enutilisant des SMS grâce à lutilisation dune passerelle SMS.Les données sont alors accessibles à lutilisateur de deux manières en générale : 1) en accédantau site internet du fournisseur de service, qui exige des honoraires mensuels. 2) en recevant lesdonnées directement sur un téléphone cellulaire, qui exige les coûts dun forfait cellulaire dedonnées. Dautres solutions existent mais il est nécessaire dacheter de léquipementsupplémentaire tel un modem GSM pour recevoir les données sur un ordinateur. [Trackgps,2008]Le schéma ci-dessous montre comment les données GPS peuvent être transmises au serveursur un réseau GPRS / Mobile: Figure III-3 : Transmission des données GPS sur un réseau GPRS / Mobile III.2.2 Choix du formalisme UMLDu moment que notre application est basée sur une architecture orientée objet, nous avons optépour le langage de modélisation UML, acronyme de « Unified Modeling language » ou enfrançais « Langage de modélisation unifié » (voir Annexe 3). En effet, UML est le langagegraphique de modélisation des données et des traitements le plus adapté aux applicationsorientées objet. Par ailleurs, UML présente bien d‟autres atouts notamment :  UML est un langage formel et normalisé  Gain en précision  Gage de stabilité  UML est un support de communication performant  Il cadre lanalyse  Il facilite la compréhension de représentations abstraites complexes  Son caractère polyvalent et sa souplesse en font un langage universel.Projet de Fin d‟études 2010-2011 38
  • 38. Chapitre 3 Analyse et conceptionNotre étude comprend les diagrammes de cas d‟utilisation, les diagrammes de classes, et undiagramme d‟activité. III.2.3 Diagrammes UML a. Diagrammes de cas d’utilisationLe système traitera deux nouveaux volets Traking et Portail et chaque volet est géré par unresponsable à part, ainsi les acteurs humains agissant sur le système sont :  Gestionnaire de la flotte (Tracking).  Responsable logistique de la société centrale (Portail).  Agent de la succursale (Portail).Pour présenter les différentes relations de notre application, nous avons établi les diagrammesd‟utilisation Tracking et Portail (figures III-4 et III-5)  Diagramme de cas d’utilisation: Module TrackingLe diagramme de cas d‟utilisation ci-dessous illustre l‟organisation des fonctionnalités dumodule « Tracking » : Module Tracking Gérer les balises <<extend>> lister les balises Annuler une affectation <<extend>> Affecter balise à un vehicule Responsable de controle <<use>> consulter la fiche véhicule Tracker un véhicule <<use>> Génerer le rapport dactivité Figure III-4 : Diagramme de cas d’utilisation du module TrackingProjet de Fin d‟études 2010-2011 39
  • 39. Chapitre 3 Analyse et conceptionAfin d‟éclaircir le diagramme ci-dessus, nous avons détaillé chaque cas d‟utilisation à partdans des tableaux explicatifs. Nous présentons dans la section suivante les cas d‟utilisations lesplus importants. i. Détails du cas d’utilisation «Gérer les balises» Cas d’utilisation : Gérer les balises GPSBut : Gérer les informations relatives aux balises.Acteur : Responsable de contrôle.Pré-condition : - L‟acteur est authentifié - La base doit être unique.Post-condition : - Toute modification sera stockée dans la base de données. Scénarii principaux1. Ajout des balises2. Supprimer une balises3. Mettre à jour les informations relatifs à une Tableau III-1: Cas d’utilisation «Gestion des balises GPS» ii. Détails du cas d’utilisation «Affecter une balise à un véhicule» Cas d’utilisation : Affecter une balise à un véhiculeBut : Associer une balise à un véhicule pour pouvoir le localiser à l‟aide di numéro de série de labalise.Acteur :  Responsable de contrôle.Pré-condition : - Le Responsable est authentifié - Le véhicule et la balise se trouvent à priori dans la base de données Scénarii principaux 1. Validation de l’affectation. 2. Modification de l’affectation. 3. Annulation de l’affectation. Tableau III-2: Cas d’utilisation «Affectation des balises GPS aux véhicules»Projet de Fin d‟études 2010-2011 40
  • 40. Chapitre 3 Analyse et conception iii. Détails du cas d’utilisation «Tracker un véhicule» et « Générer le rapport des événements » Cas d’utilisation : Tracker un véhicule, Générer le rapport des événementsBut : Garder la trace des véhicules en localisant les balises associées à ces véhicules.Acteur :  Responsable de contrôlePré-condition : - Le responsable est authentifié - Le responsable doit sélectionner le camion à suivre via la fiche véhicule. - Le véhicule doit disposer d‟une balise. Scénarii principaux 1. Connexion à OpenGTS 2. Suivre le mouvement des véhicules 3. Générer un rapport d’événements Tableau III-3: Cas dutilisation « Tracker un véhicule, Générer le rapport des événements »  Diagramme de cas d’utilisation: Module Portail TMS.Le diagramme ci-dessous regroupe les principales fonctionnalités du module portail, ainsi queles différentes interventions des acteurs qui l‟utilisent. Cependant, les cas d‟utilisations „Créerune commande‟, „Créer une ligne de commande‟, „Affecter un véhicule à un voyage‟ et„Facturer un voyage‟ sont déjà exprimés dans l‟ancien système.Projet de Fin d‟études 2010-2011 41
  • 41. Chapitre 3 Analyse et conception Module Portail TMS Indiquer les palettes en allé <<extend>> Demander un voyage <<include>> Gestion de voyage Portail <<include>> Agent succurcale Planifier un voyage <<include>> <<include>> Valider un voyageResponsable logistique Alerter la reception de la livraison <<extend>> Indiquer les palettes en retour Figure III-5 : Diagramme de cas d’utilisation du module Portail TMS b. Diagramme de packages Le diagramme de packages fournit une représentation graphique de haut niveau de lorganisation de notre application, et nous aide à identifier les liens de dépendance entre les packages. Projet de Fin d‟études 2010-2011 42
  • 42. Chapitre 3 Analyse et conception Tms_Tracking RH Tms_Parc Tms_Portail Tms_Voyage Tms_commision Produit Comptabilité Tms_Planification Ventes Achats Tms_GMAO Figure III-6 : Diagramme de packages c. Diagrammes de classesLe diagramme de classes montre la structure interne du système. Il permet de fournir unereprésentation abstraite des objets du système, qui vont interagir ensemble pour réaliser les casd‟utilisation. i. Module Tracking D‟après l‟analyse faite précédemment, le système doit posséder une classe « Device ». Ainsi,chaque balise sera attachée à un véhicule pour permettre sa localisation GPS.D‟autre part, la classe « Affectation » s‟occupera des détails des affectations réalisées.A ce stade, nous pouvons déterminer les classes candidates du diagramme de classe: Classe DescriptionDevice Représente les balises GPSVehicule Caractérise les véhicules à trackerAffectation Représente les associations balises-véhicules Tableau III-4: Liste des classes du module « Tracking »La figure de la page suivante représente le diagramme de classes que nous avons pu élaboreraprès une étude détaillée des fonctionnalités du système.Projet de Fin d‟études 2010-2011 43
  • 43. Chapitre 3 Analyse et conception Module Tracking Affectation - Affectation_ID : char - Date_affectation : Date - Date_annulation : Date - Notes : char + _affecter () + _annuler () Vehicule - Matricule : char Device - Modele : char - - Num_chassi : char - Device_ID : char - Compteur : int 1..* - Marque : char - Date_entre : Date - Etat : char 1..* - Accident : int - Statut : char - poids_vide : int + <<Getter>> getStatut () : char - pods_total : int + <<Setter>> setStatut (char newStatut) : void - prix_achat : int + _accroche_sremorque () Figure III-7 : Diagramme de classe du module Tracking ii. Module Portail TMSLe système est basé sur la classe «Voyage » qui doit être en relation avec la classe« Ligne_commande » se trouvant dans le package Tms_voyage. Par ailleurs, le portail doitpermettre aux utilisateurs de faire des remarques et de choisir les palettes transportées en allé eten retour à travers les classes « Remarque » et « palette ».A ce stade, nous pouvons déterminer les classes candidates du diagramme de classe: Classe DescriptionVoyage Représente l‟entité voyageLigne_commande Représente les enregistrements dans une commandeCommande Représente les commandes passées par les clientsTrajet Caractérise le trajet parcouru dans chaque voyageFacturation Décrit les factures détailléesPalette Représente les palettes de marchandise à transporterMarchandise Caractérise les types de marchandiseProjet de Fin d‟études 2010-2011 44
  • 44. Chapitre 3 Analyse et conception Remarque Représente les remarques faites dans toutes les étapes du voyage Vehicule Représente les camions (appartient au package Tms_parc) Tableau III-5 : Liste des classes du module « Portail TMS » La figure suivante présente le diagramme de classes que nous avons pu élaborer après une étude détaillée des fonctionnalités du portail. Commande - Ref_commande : char - Date_debut : Date - Date_fin : Date - Bateau : char - Client : char - Adresse _livraison : char - Adresse_facturation : char - liste_prix : char + Operation_1 () 1..1 1..* Gestion de commande ligne_commande - Order_ID : char - Sequence : int Trajet - Price_unit : float - Product_uom : char - Nom_trajet : char - product_qty : float - Reference : char - Invoiced : boolean 1..* - Uom : char - Discout : float - Kilometrage_estime : int 1..1 - Frais_autoroute : int - Delay : int - Name : char - Comission_chaffeur : char - Notes : char - State : char 1..1 Remarque 1..* tms_facturation- Remarque_ID : int tms_voyage - Nom_facture : char- Objet : char 0..* - Voyage_id : char - Observation : char 1..*- Date : Date 0..1 - Statut : char - Date_facture : Date 1..1- Description : char - Date_debut : Date - Bon_facture : char - Date_fin : Date - Reffect : char - Date_livraison : Date - Type : char - Qte_livre : int - Qte_facture : int 0..* Vehicule 1..* 1..* - Matricule : char - Modele : char OR 1..1 - Num_chassi : char Palette 1..* 1..* - Compteur : int Retour Palette Alllé - Date_entre : Date Palette - Accident : int Marchandise - poids_vide : int - Reference : char - palette_ID : char - pods_total : int 1..1 - Nombre_palette : int - Nom : int - prix_achat : int 1..* - Notes : char + _accroche_sremorque () + _calcul_total () Figure III-8 : Diagramme de classes du module Poratail TMS Projet de Fin d‟études 2010-2011 45
  • 45. Chapitre 3 Analyse et conception d. Diagramme d’activité du module Portail TMSLe diagramme d‟activité permet de représenter la dynamique du système. Il montrel‟enchainement des activités faites à travers le portail TMS depuis la demande du voyagejusqu‟à sa facturation. Agent Agent de la succurcale Responsable Logistique Ajouter un voyage Créer une commande Ajouter les palettes dallé Planifier un voyage Créer une ligne de commande >26 Nbre palettes Valider un voyage <= 26 Affecter un véhicule au voyage Non Alerter la reception de livraison Disponibilité camion Spécifier les palettes en retout Oui Facturer voyage Figure III-9 : Diagramme d’activité du module Portail III.3 Etude fonctionnelle du module GMAOLe triplet Qualité – Délai – Coût est devenu la devise de toutes les entreprises qui désirentdemeurer actives dans un environnement de plus en plus imprévisible, et où le client disposed‟un grand choix de produits et de services.L‟entreprise se trouve, entre autre, devant l‟obligation de maximiser la fiabilité et ladisponibilité de son outil et de ses ressources matérielles.La défaillance d‟une ou de plusieurs installations représente à chaque fois un événementindésirable, souvent lourd de conséquences au niveau économique et parfois même au niveausocial.Projet de Fin d‟études 2010-2011 46
  • 46. Chapitre 3 Analyse et conceptionEn plus d‟affecter directement la qualité du service et d‟accroître le prix de revient,l‟indisponibilité des équipements constitue un obstacle majeur au respect des délais.Il est donc nécessaire de concevoir, d‟implanter et de bien gérer des programmes rigoureux demaintenance, qui permettent de réduire au minimum la fréquence et la durée des interruptionsaccidentelles de service, tout en respectant les contraintes sur la disponibilité des ressources(budget, main-d‟œuvre, pièces de rechange …etc.).Comme dans beaucoup de domaines, la maintenance a subi des changements profonds autantau niveau des méthodes de gestion des opérations qu‟au niveau des moyens techniques mis enœuvre pour assurer une disponibilité maximale des équipements et ce, à coût minimum. Il y‟ale constat que lutilisation dun progiciel / logiciel de GMAO est devenue un outilincontournable de gestion technico-budgétaire puisque elle permet de :1- Minimiser la fréquence des pannes : Par létablissement dun programme rigoureux dactionspréventives dont le déclenchement automatique et le suivi se font à laide de lordinateur.2- Minimiser la durée des arrêts de production suite à des pannes : Par lélaboration et la miseen œuvre de procédures daide au diagnostic rapide des pannes.3- Réduire la taille et le coût de linventaire des pièces de rechange : Par limplantation dunsuivi automatique des quantités minimales, maximales et de commande de chaque pièce derechange dans le but déviter le sur-stockage dune part, et les pénuries de stock dautre part.4- Minimiser les coûts de maintenance : Par la réduction de la fréquence et de la durée despannes dune part, et la gestion rationnelle de lapprovisionnement et de lutilisation des piècesde rechange, dautre part.7- Préserver le savoir-faire : Loutil informatique permet le stockage " intelligent " de tous lesparamètres concernant les interventions de maintenance (préventive et corrective): lesfréquences des actions préventives, les causes de chaque panne et les remèdes apportés, lescoûts reliés à chaque intervention, les pièces consommées, les outils utilisés, etc. Ceci permet,entre autres, de préserver le savoir-faire précieux souvent détenu de manière informelle parcertaines personnes expérimentées au sein de lentreprise et qui sont naturellement voués àpartir un jour ! Si leur savoir-faire est préservé, il serait possible dintégrer dans les meilleuresconditions (rapidité, efficacité) les nouvelles recrues, tout en assurant une bonne homogénéitédes prestations.En général on distingue deux types de maintenance : - Maintenance Préventive : maintenance exécutée à des intervalles prédéterminés ou selon des critères prescrits et destinées à réduire la probabilité de défaillance ou la dégradation du fonctionnement d‟un bien. - Maintenance corrective : maintenance exécutée après détection d‟une panne et destinée à remettre un bien dans un état dans lequel il peut accomplir une fonction requise.Projet de Fin d‟études 2010-2011 47
  • 47. Chapitre 3 Analyse et conceptionPour mieux comprendre ces deux démarches, on a opté pour la méthode ARIS, qui focaliseplus l‟analyse et l‟organisation des systèmes sur les processus de mise en œuvre.Une modélisation ARIS de la gestion de la maintenance préventive, ainsi que la maintenancecorrective sont indiqués respectivement dans les deux figures ci-après : Figure III-10 : Modélisation ARIS de la gestion de la maintenance correctiveProjet de Fin d‟études 2010-2011 48
  • 48. Chapitre 3 Analyse et conception Figure III-11 : Modélisation ARIS de la gestion de la maintenance préventiveConclusionDans ce chapitre, nous avons présenté les différents diagrammes élaborés qui nous ont permisde cerner les différentes fonctionnalités du futur système avant de passer à la phase deréalisation. Dans le chapitre suivant, nous abordons l‟architecture du système et nousprésenterons les différents outils utilisés.Projet de Fin d‟études 2010-2011 49
  • 49. Chapitre 4 Réalisation et mise en œuvreChapitre IVEtude technique et réalisation du projetCe chapitre met la lumière sur la plateforme utilisée et les outils de développement adoptés à fin de mettre enœuvre l’application. Nous y décrivons la démarche suivie pendant la réalisation et nous illustrons certaines fonctionnalités assurées à travers quelques interfaces.Projet de Fin d‟Etudes 2010-2011 50
  • 50. Chapitre 4 Réalisation et mise en œuvreIV. Etude technique et réalisation du projet IV.1 Etude techniqueLes entreprises recherchent, de plus en plus, des solutions à moindre coûts, mais tout enrespectant les standards de qualité logicielle. C‟est dans ce sens que Systemum a développéune expertise sur OpenERP, solution open source (voir Annexe 1) sur laquelle se base laplupart des solutions développées au sein de la société. Ce modèle consiste à facturer au clientnon pas le logiciel lui-même, qui reste open source, mais le service de support, dinstallation,de personnalisation, de configuration et de maintenance IV.1.1 OpenERP a. Description d’OpenERPOpenERP (ancien TinyERP) est un logiciel de gestion intégré libre, issu dun projetcollaboratif. De ce fait, il dispose dun réseau de développeurs mondial qui est coordonné parla société belge Tinysprl. Ce mode de développement lui permet de disposer dun grandnombre de modules (qui dépasse aujourd‟hui 1000 modules) et par la même occasion dunegrande flexibilité.OpenERP couvre pratiquement tous les secteurs d‟activités : industrie, commerce,prestations de services, E-Commerce, négoce, etc. Comme la plupart des logiciels libres,laccessibilité, la flexibilité et la simplicité sont les maîtres mots du développement. b. Architecture modulaire d’OpenERPUn module OpenERP est la définition, dans le « Framework » OpenERP, d‟une gestioninformatisée d‟un domaine.Cette architecture n‟est pas propre à open ERP. Elle est en fait partagée par tous lesERP. Il s‟agit de la faculté de construire des applications informatique de manière modulaire(modules indépendants entre eux) tout en partageant une base de données unique. Ceciapporte une importance significative puisque les données sont maintenant standardiséeset partagées. Ce qui élimine les saisies multiples et évite lambiguïté des données demême nature. L‟architecture modulaire d‟open ERP lui permet de couvrir plusieursdomaines, dont on cite : Finance te comptabilité, Les ressources humaines, LA logistique etCRM. Comme illustrés sur la figure suivante :Projet de Fin d‟Etudes 2010-2011 51
  • 51. Chapitre 4 Réalisation et mise en œuvre • générale. •la paie. •analytique. •congés. •budgétaire. •projet. Finance et ressources comptabilité humaines •production. Logistiques CRM •stocks. •Gestion •maintenance. commerciale. •Marketing. •Gestion des affaires Figure IV-1 : Architecture modulaire d’open ERP c. Architecture d’OpenERPOpenERP est basé sur une architecture client/serveur. Le serveur et le clientcommuniquent via le protocole XML-RPC. C‟est un simple protocole qui permet au client defaire des appels aux procédures. Une fois la fonction est appelée, ses arguments et sesrésultats sont envoyés par le protocole http, eux-mêmes sont encodés par le langage XML.OpenERP est couplé à une base de données PostgreSQL. De plus, il est compatible au packOpen Office, et aussi avec des outils de reporting (ReportLab) pour produire desrapports en PDF ou en HTML. Figure IV-2 : Architecture Client-Serveur d’OpenERPProjet de Fin d‟Etudes 2010-2011 52
  • 52. Chapitre 4 Réalisation et mise en œuvreLa logique d‟open ERP est entièrement du côté serveur. La tâche du client se résume àdemander les données (formulaire ou listes) au serveur et de les renvoyer. Avec cetteapproche, presque tout le développement est fait du côté serveur. Ce qui rend OpenERP plussimple au développement et à la maintenance.Lopération client est très simple. Quand un utilisateur exécute une action (sauvegarder unformulaire, ouvrir un menu ou imprimer) il envoie cette action au serveur. Le serveur envoiealors la nouvelle action pour sexécuter côté client. Il y a trois types dactions à distinguer : - Ouvrir une fenêtre (formulaire, listes) - Imprimer un document. - Exécuter un wizard. d. Le Framework de développement OpenObjectOpenERP offre un cadre de développement, c‟est à dire des «services» techniquesinformatiques : - Un serveur de base de données objet pour représenter et mémoriser les objets de gestion et les rendre accessible via le réseau. - Un "workflow" qui contrôle l‟évolution des objets suivant une procédure. - Des formulaires et écrans pour l‟interaction avec l‟utilisateur. - Des états imprimables des objets.Chaque module doit nécessairement contenir au moins les quatre fichiers : _init_.py, _terp_.py,module_name.py, module_name_view.xml : [OpenERP Doc, 2010] Figure IV-3 : Architecture dun module dOpenERPProjet de Fin d‟Etudes 2010-2011 53
  • 53. Chapitre 4 Réalisation et mise en œuvre IV.1.2 Le langage PythonLe langage de programmation utilisé par OpenERP est Python, un langage portable,dynamique, extensible, gratuit, qui permet (sans limposer) une approche modulaire etorientée objet de la programmation. Python est développé depuis 1989 par Guido vanRossum et de nombreux contributeurs bénévoles. IV.1.3 PostgreSQLPostgreSQL est un SGBD très performant sous licence BSD dont les performances sontcomparables à Oracle 9.PostgreSQL remonte à la base de données Ingres, développée à Berkeley par MichelStonebraker. C‟est un outil libre disponible selon les termes d‟une licence de type BSD(voir Annexe 1). Ce système est concurrent à d‟autres systèmes de gestion de base de données,qu‟ils soient libres (comme MySQL et Firebird), ou propriétaire (comme Oracle, Sybase).Comme les projets libres Apache et Linux, PosgreSQL n‟est pas contrôlé par une seuleentreprise, mais fondé sur une communauté mondiale de développeurs et d‟entreprises. IV.2 Interfaces graphiquesDurant cette section, nous présentons les scénarios d‟utilisation des modules développés, ouparamétrés de l‟application par quelques interfaces. IV.3.1 Paramétrage du module gestion de voyageComme expliqué en analyse, on a décidé de faire hériter les trajets du module « Produit »d‟OpenERP. Ainsi on trouve sur la figure ci-dessous la liste des trajets enregistrés sur la base :Projet de Fin d‟Etudes 2010-2011 54
  • 54. Chapitre 4 Réalisation et mise en œuvre Figure IV-4 : Liste des trajetsL‟interface suivante illustre la création des variantes (Forfait Solo, Forfait S/R, Km et Tonne)d‟un trajet à partir du trajet model Marrakech – Casablanca :Projet de Fin d‟Etudes 2010-2011 55
  • 55. Chapitre 4 Réalisation et mise en œuvre Figure IV-5 : Création des variantes du trajet Projet de Fin d‟Etudes 2010-2011 56
  • 56. Chapitre 4 Réalisation et mise en œuvreAprès avoir créé les trajets et précisé ses variantes.L‟utilisateur passe par le menu principal de l‟interface présentée sur la figure ci-dessous pourcréer une ligne de commande, dès qu‟il reçoit une commande. Ceci en choisissant le trajet, eten précisant les remises et la taxe. Le prix (fournit par la liste de prix ) associé au client, ainsique les autres informations sont automatiquement remplis. Figure IV-6 : Ligne de commandeLa figure suivante montre la création d‟une nouvelle liste de prix pour le client LP_LESIEUR,pour le trajet CASA-MARRAKECH en Km :Projet de Fin d‟Etudes 2010-2011 57
  • 57. Chapitre 4 Réalisation et mise en œuvre Figure IV-7 : Liste des prix Projet de Fin d‟Etudes 2010-2011 58
  • 58. Chapitre 4 Réalisation et mise en œuvre IV.3.2 Module trackingLa figure ci-dessous présente le menu principal et les sous menus du module tracking : Figure IV-8: Menu du module TrackingL‟ajout d‟une nouvelle balise passe par le remplissage des champs de la figure suivante : Figure IV-9: Formulaire dajout dune balise GPSProjet de Fin d‟Etudes 2010-2011 59
  • 59. Chapitre 4 Réalisation et mise en œuvreL‟association d‟une balise à un véhicule se fait en confirmant l‟affectation comme présentéedans l‟interface suivante : Figure IV-10: Interface daffectation des balises GPS aux véhiculesLa figure suivante montre le déclanchement d‟une exception au niveau de l‟affectation, si labalise est déjà affectée à un véhicule. Figure IV-11 : Contrôle sur les balises déjà affectéesL‟installation du module tracking ajoute un onglet « Tracking » à la fiche des véhicules,comme illustré sur la figure suivante :Projet de Fin d‟Etudes 2010-2011 60
  • 60. Chapitre 4 Réalisation et mise en œuvre Figure IV-12 : Onglet de Tracking se trouvant dans la fiche véhiculeLe bouton « suivi du véhicule » permet de suivre les véhicules choisis sur la carte google-maps(Figure IV-13 et Figure IV-14) et le bouton « Rapport d‟évènements » génère un rapport desdifférents évènements du véhicule (Figure IV-15).Projet de Fin d‟Etudes 2010-2011 61
  • 61. Chapitre 4 Réalisation et mise en œuvre Figure IV-13 : Tracking par OpenGTS (Sattelite) Figure IV-14 : Tracking par OpenGTS (Plan) Projet de Fin d‟Etudes 2010-2011 62
  • 62. Chapitre 4 Réalisation et mise en œuvre Figure IV-15 : Rapport d’évènementsProjet de Fin d‟Etudes 2010-2011 63
  • 63. Chapitre 4 Réalisation et mise en œuvre IV.3.3 Module Portail TMSA travers l‟onglet « Portail TMS » ajouté à l‟interface du module « Partenaire », nous pouvonsspécifier la manière d‟authentification pour l‟agent et le responsable de la société cliente : Figure IV-16 : Création dun clientUne fois l‟utilisateur a.eae créé, il doit s‟authentifier pour accéder au portail, comme illustrerci-dessous : Figure IV-17 : Page d’authentificationProjet de Fin d‟Etudes 2010-2011 64
  • 64. Chapitre 4 Réalisation et mise en œuvreLe client peut planifier ses propres voyages et consulter la liste de tous ses voyages : Figure IV-18 : linterface clientEn choisissant l‟option « planifier un voyage », le client a besoin de procurer les informationssuivantes : Reference du voyage, la date de livraison, la quantité livrée ou nombre de voyages. Figure IV-19 : Planification dun voyage par le clientProjet de Fin d‟Etudes 2010-2011 65
  • 65. Chapitre 4 Réalisation et mise en œuvre Les informations sur les palettes à transporter sont à fournir comme figuré ci-dessous : Figure IV-20 : Ajout des palettes à transporterUne fois le voyage est validé par le responsable logistique c‟est à la société de transport d‟affecter uncamion et un chauffeur à ce voyage : Figure IV-21 : Affectation des véhicules aux voyagesOn peut aussi renseigner les palettes de retour comme le montre la figure suivante : Projet de Fin d‟Etudes 2010-2011 66
  • 66. Chapitre 4 Réalisation et mise en œuvre Figure IV-22 : Ajout des palettes de retourConclusionAu terme de ce chapitre, nous avons défini la démarche de mise en œuvre ainsi que laprésentation de quelques interfaces de l‟application.Projet de Fin d‟Etudes 2010-2011 67
  • 67. Conclusion et perspectives Conclusion et perspectivesDans un souci de gérer en amant le changement que ça soit au niveau des besoins utilisateurs,des technologies, des règles métier ou des organisations, notre mission consistait à lapréparation d‟un socle fonctionnel basé sur l‟étude et le benchmarking des solutions TMS,ainsi que le redéveloppement de l‟application OpenTMS remédiant à la fois aux lacunes etlimites de la première version et étendant ses fonctionnalités, tout en bénéficiant des apports dela méthode agile XP dans la conduite du projet et du progiciel OpenERP comme support dedéveloppement.Le stage effectué au sein de Systemum nous a donné l‟occasion de faire le lien entre lesconnaissances académiques, notamment en matière de logistique et transport, et le mondeprofessionnel.D‟une part, il nous a permis de développer nos compétences techniques, d‟approfondir nosconnaissances théoriques et pratiques, de stimule un esprit d‟initiative et de créativité, etd‟apprendre le métier du secteur du transport.D‟autre part, l‟environnement de travail, au sein d‟une équipe, nous a donné l‟occasiond‟améliorer notre savoir-faire, de travailler avec rigueur et d‟affermir un esprit d‟équipe et deprofessionnalisme. Enfin, cette expérience a aiguisé nos capacités d‟analyse, de conception etde synthèse et a surtout fortifié notre motivation, détermination et ambition.Le projet poursuivra son développement en ouvrant la voie vers les nouvelles fonctionnalitésqui peuvent éventuellement immerger. Notre perspective est d‟achever d‟abord la conceptiondu module GMAO à travers les différentes vues de la méthode ARIS (vue fonctionnelle, vuorganisationnelle, vue de données) et de l‟implémenter ensuite. Par ailleurs, il serait intéressantque le système soit capable non seulement de délivrer des informations statistiques, mais aussid‟interpréter ces résultats pour aider l‟opérateur à prendre des décisions pertinentes enconstruisant des stratégies de maintenance.Projet de Fin d‟Etudes 2010-2011 68
  • 68. Bibliographie Bibliographie  Ouvrages : - [Gérard Swinnen, 2009], Apprendre à programmer avec Python, Paris, EYROLES, 2009, 361. - [Fabien Pinckaers, 2008], OpenERP pour une gestion d’entreprise efficace et intégrée, Paris, EYROLES, 2008, 298. - [Yves Pimor, 2008], LOGISTIQUE Production – Distribution - Soutien, Paris, DUNOD, 2008, 766.  Cours : - [Boukachour, 2011] Jaouad Boukachour, « Cours #4 » Système d’Information Logistique, 2011  Documents : - [Ndiaye, 2011] Ndiaye Abdoulay, « Rapport Transport Management System (TMS) », INSSET, 2011, 57 p.  Projets de fin d‟études : - [ABDOUNI et al, 2010] Souhayl ABDOUNI et Anas AFIF, Automatisation du reporting et la planification des ressources pour le projet TMA-Maroc Telecom, ENSIAS, 2010, 119 p. - [EL HAMIDI, 2009] Ahmed EL HAMIDI, Conception et réalisation d’un module de gestion de la paie marocaine sous OpenERP, ENSAT, 2009, 98 p.  Webographie - [2009] Disponible sur : http://www.faq-logistique.com/TMS;html,, 04/05/2011 - [Systemum, 2010] Systemum Entreprise, site officielle de Systemum, [Hors ligne] Disponible sur : http://www.systemum.com, 20/05/2011 - [OpenERP Apps, 2011] OpenERP Entreprise, Modules OpenERP, [Hors ligne], Disponible sur : http://apps.openerp.com - [OpenERP Doc, 2010] OpenERP Enterprise, OpenERP documentation v6, [Hors ligne] Disponible sur : http://doc.openerp.com, 01/04/2011 - [Trackgps, 2008] Trackgps Entreprise, Solution de localisation GPS Temps réel [Hors ligne], Disponible sur : http ://www.trackgps.com/fr/index.php/information.phpProjet de Fin d‟Etudes 2010-2011 69
  • 69. Annexes Annexe 1 : L’Open Source1.1 Définition Un logiciel open source est un logiciel qui est fourni avec lautorisation pourquelconque de lutiliser, de le copier, et de le distribuer, soit sous une forme conforme àloriginal, soit avec des modifications, ou encore gratuitement ou contre un certain montant.Ceci signifie en particulier que son code source doit être disponible.1.2 Principes La Free Software Foundation maintient une définition du logiciel libre basée surquatre libertés : Liberté 1 : La liberté dexécuter le programme, pour tous les usages Liberté 2 : La liberté détudier le fonctionnement du programme. Ceci suppose laccèsau code source. Liberté 3 : La liberté de redistribuer des copies. Ceci comprend la liberté de vendre descopies. Liberté 4 : La liberté daméliorer le programme et de publier ses améliorations.De part ces libertés, les utilisateurs, les développeurs et les entreprises jouissent des mêmesdroits que le propriétaire du programme, excepté son droit de propriété.1.3 Licences Open Source À lexception des logiciels dans le domaine public, les logiciels libres sont protégéscomme tout logiciel par le droit dauteur. La particularité des logiciels libres est que lauteurrenonce à lexclusivité de la plupart des droits que lui donne le droit dauteur. Il distribue lelogiciel accompagné dune licence libre qui énumère les droits donnés à lutilisateur.Certaines licences, dont la plus connue et utilisée pour les logiciels libres, la licence publiquegénérale GNU, sont relativement complexes. Ainsi la GPL ne donne le droit de redistribuerun logiciel que si lensemble du logiciel, y compris toutes les éventuelles modifications, sontredistribuées selon les termes exacts de la GPL. Cette licence est dite virale ou contaminante,car si elle autorise la fusion dun logiciel sous GPL avec un logiciel sous une autre licence,elle nautorise en revanche la redistribution de la fusion que sous GPL.Les licences des logiciels libres sont souvent divisées en deux, selon le degré de libertéaccordé par la licence en matière de redistribution.Projet de Fin d‟études 2010-2011 70
  • 70. Annexes 1.3.1 Licence BSD Il sagit des licences qui offrent la plus grande liberté. En général, seule la citation desauteurs originaux est demandée. En particulier, ces licences permettent de redistribuer unlogiciel libre sous une forme non libre. Ces licences permettent donc à tout acteur de changerla licence sous laquelle le logiciel est distribué. Un cas de changement de licence courant estlintégration de logiciel sous licence BSD dans un logiciel sous copyleft (licence GPL). Unautre cas courant est lintégration de logiciel sous licence BSD dans les logiciels propriétaires. 1.3.2 Licence GPL Il sagit des licences qui obligent la redistribution sous une licence libre. Les licencesdu projet GNU sont les plus célèbres. Une telle licence permet dintégrer du logiciel souslicence BSD et de le redistribuer sous licence GPL, alors que linverse est impossible. Le degré de liberté moindre des licences de type copyleft a été critiqué par des acteursdes projets BSD et des acteurs commerciaux; Ce qui a poussé la Free Software Fondation àproposer la LGPL. La différence entre GPL et LGPL réside principalement dans le fait que laLGPL permet de lier un programme tiers non GPL à une bibliothèque LGPL, sans pour autantrévoquer la licence. Ainsi, il devient possible à un programmeur désireux de faire un logiciel propriétairedutiliser certains outils du libre (ex: la bibliothèque graphique GTK).1.4 Le modèle économique Le modèle économique des SSLL (sociétés de services en logiciels libres) est liéprincipalement à la notion de service : vendre un savoir-faire et une expertise plutôt quundroit dusage sur un logiciel.Ce modèle consiste à facturer au client non pas le logiciel lui-même, qui reste open source,mais le service de support, dinstallation, de personnalisation, de configuration et demaintenance que lon vend autour sous forme dabonnement.Un autre système payant, utilisé par dillustres éditeurs de logiciels libres comme MySQL,consiste en une licence commerciale quachètent certains clients afin dintégrer le produit libredans leurs propres produits dans le but de les redistribuer de manière payante, avec un codesource fermé.Une troisième forme de financement pour les éditeurs de logiciels libres est lorganisation deséminaires pour la présentation des solutions open source au grand public, notamment auxcommerciaux.Le modèle économique des logiciels open source a suscité toutefois certaines critiques :Projet de Fin d‟études 2010-2011 71
  • 71. Annexes - Incompatibilité entre les besoins des clients et les demandes de la communauté. - Les revenues sont générés par le service, et non pas par le logiciel lui-même. - Difficulté du maintien sur le long terme dune ressource humaine compétente et capable de tenir des délais compatibles avec la notion de service.1.5 Avantages et limitations de l’open source 1.5.1 Avantages - Des logiciels de qualité - Un programmeur qui expose son code au monde et aux autres participants du projetfera en sorte que le code soit de qualité. Si ce nest pas le cas, un autre programmeur du projetproposera à la place un code plus efficace ou plus propre. De plus, un grand nombre depersonnes participent en permanence aux tests des logiciels libres, ce qui permet didentifierles bugs très tôt. - Un coût raisonnable pour les utilisateurs - Les logiciels Open Source sont soit gratuits soit proposés à un coût raisonnable, danstous les cas inférieur à celui des logiciels commerciaux équivalents - Si des bugs sont identifiés, la prise en compte de la correction de ces erreurs estassurée gratuitement par les participants du projet. - Une forte réactivité - En général les utilisateurs ayant un besoin précis damélioration du logiciel reçoiventun écho favorable et rapide de la part de la communauté des développeurs du projet. Unutilisateur peut lui même coder une fonctionnalité dont il a besoin, en accord avec lecoordonnateur du projet. - Des logiciels à long terme - Les projets aboutis de logiciels libres ont une très longue durée de vie, car il y atoujours des volontaires pour poursuivre le projet. 1.5.2 Limitations - Les obstacles financiersLes façons de génération de profits restent assez restreintes en quantité et en qualité. - Orientation vers les aspects techniquesProjet de Fin d‟études 2010-2011 72
  • 72. AnnexesLa plupart des projets Open Source réussis concernent des "logiciels techniques", cest-à-diredes logiciels non pas applicatifs mais remplissant une fonctionnalité technique utilisée pardautres logiciels. - Le support et la formation des utilisateursBeaucoup dutilisateurs de logiciels ont besoin non seulement dun support technique pointupour corriger les bugs éventuels, mais surtout dun support de base pour être aidé danslutilisation du logiciel, voire de formations. - Le marketing et linertie de marchéLes premiers projets Open Source ne disposaient pas de budgets marketing. Cependant, onvoit apparaître de plus en plus de projets Open Source appuyés ou financés par des éditeurs delogiciels ou des intégrateurs.Projet de Fin d‟études 2010-2011 73
  • 73. Annexes Annexe 2 : Partie du livre blanc TMS2.1 A qui s’adressent les TMS? Deux besoins différents existent et donc, de deux points de vue on peut aborder lesproblèmes de transport. Les besoins coté chargeurs (expéditeurs, donneurs d‟ordre) et lesbesoins côté prestataires logistiques (3PL, transporteurs, commissionnaires de transport,transitaires...). La première vise les acheteurs de transport, ce qui regroupe déjà des métiers etdes problématiques transport aussi vastes que différents prestataire logistique 3PL ou 4PL. Ladeuxième en général, réalisées par des éditeurs nouant des partenariats avec des fabricants dehardware (de terminaux embarques) - L‟approche TMS chargeurs est généralement portée sur l‟optimisation des achats de transport. En effet, le chargeur n‟ayant pas directement de contrainte sur l‟exploitation des transports et l‟optimisation du coût de production des transports s‟attachera à travailler la répartition de ses ordres de transport auprès des transporteurs, en fonction des coûts de prestation, les fonctions d‟évaluation des coûts de transport sur la base de grilles tarifaires, l‟organisation d‟appels d‟offres, la simulation tarifaire sont alors des outils bien utiles. - Pour les transporteurs, la maîtrise des coûts d‟exploitation transport est essentielle. Le TMS transporteur se focalisera par conséquent sur le but de rentabiliser l‟utilisation des moyens à sa disposition en organisant sa production. On parle alors d‟optimisation de tournées, d‟optimisation de réseau, de gestion de contraintes sociales, de valorisation des transports en fonction des distances parcourues.Alors que les éditeurs de progiciels débattent de ce qu‟est un TMS, les besoins destransporteurs et des chargeurs évoluent. En effet, certains transporteurs, se positionnant surdes prestations globalisées, s‟équipent de solutions incluant des fonctions d‟affrètementpropres aux TMS chargeur. De même, certains industriels chargeurs, voyant leurs besoins entransport s‟équilibrer sur des boucles, cherchent à produire leurs propres transports etrequirent par conséquent des fonctions de TMS transporteur.En conclusion, la réponse à la question des différences à faire entre les progiciels TMSchargeur et TMS transporteurs est une réponse à géométrie variable, directement liée à cequ‟on souhaite mettre en place.2.2 Structure d’un TMS Tout d‟abord, le TMS intervient au niveau stratégique (orienté chargeurs) : il s‟agitde définir le réseau de transport, c‟est-à-dire de concevoir le schéma optimal de transport avecle nombre, le type et l‟emplacement des plateformes logistiques, d‟étudier les impacts del‟implantation de nouvelles plates-formes, et d‟optimiser les achats de transport (sourcingProjet de Fin d‟études 2010-2011 74
  • 74. Annexesstratégique) en tenant compte des tarifs, des volumes et des niveaux de services destransporteurs.Au niveau tactique, on trouve des outils de simulation afin de tester différents scénarios(“what-if” scénarios) pour aboutir à des plans de transport sur un horizon de plusieurs mois.Ce segment concerne particulièrement le marché des prestataires logistiques qui optimisentleur propre plan de transport ainsi que celui de leurs clients, et des sociétés qui pilotent unréseau transport complexe (de distribution par exemple).Au niveau opérationnel, on commence un travail d‟élaboration à plus court terme : leplanificateur organise les tournées au quotidien en tenant compte des commandes réelles, dela disponibilité des moyens matériels et des ressources humaines ; il définit ainsi un planopérationnel de transport exécutable. Cela concerne des sociétés ayant des tournéescomplexes et variables ou assurant la gestion d‟une flotte dédiée (en propre ou non) pourpermettre l‟affectation des moyens et des ressources aux tournées.Ces fonctionnalités sont généralement couplées avec des fonctionnalités d‟exécution et desuivi.Au niveau de l’exécution et du suivi, le TMS couvre l‟exécution des opérations de transport(ex : outils de type affrètement ou exploitation du réseau), les besoins de traçabilité : captureet gestion des évènements de transport; et les besoins d‟analyse de la performance et desstatistiques. Il faut donc gérer les demandes de transport (émises par différentes parties),consolider ces demandes pour constituer des chargements et des routes avec des optimisationssimples (en cas de complexité plus forte un logiciel d‟optimisation de tournées s‟avèrenécessaire).Ces fonctionnalités peuvent être résumées dans le schéma suivant surnommé le cerclevertueux du transport.Projet de Fin d‟études 2010-2011 75
  • 75. Annexes2.3 Les points de vigilance dans la mise en place d’un TMSOn entend dire par TMS ici, une solution étendue de la gestion du transport, cest-à-direcouvrant la gestion des flux de marchandises, depuis les fournisseurs jusqu‟aux clients finaux,par opposition à une solution ciblée qui consiste à mettre en place une « brique » bienspécifique comme l‟optimisation des tournées, le tracking des véhicules…, et qui nenécessiterait pas forcement une démarche projet identique.En s‟appuyant sur diverses expériences des cabinets de conseil et des intégrateurs dessystèmes d‟information, nous avons développé ci-après les points de vigilance à retenir, toutau long de la mise en place du TMS.2.3.1 Phase d’expression des besoins et sélection du panel des éditeursLe TMS peut être un formidable outil de management du transport mais encore faut-il, dès ledépart, clarifier quelques principes fondamentaux.Un premier élément à déterminer est la couverture du TMS par rapport à l‟ensemble desflux transports à gérer au sein de l‟entreprise : faut-il prendre en considération des flux amont,en plus des flux transport aval, qu‟il faut éventuellement acheminer à l‟international ? Cettequestion de couverture géographique est primordiale car, outre la dimension plus globale duprojet, elle peut également avoir des impacts sur l‟organisation du transport et amener, parexemple, à remettre en cause une gestion décentralisée du transport. En tout état de cause, ellesera déterminante sur le choix du TMS, car il faudra alors s‟orienter vers un outil assurant letransport multimodal et permettant une visibilité des flux depuis le fournisseur jusqu‟au clientfinal.Un deuxième point sur lequel on doit s‟interroger est le positionnement de l‟organisationtransport, (cf. schéma ci-dessous), dans la chaîne logistique globale, à savoir : est-on dans unelogique de flux tirés ou flux poussés ? Ce qui va avoir un impact sur les relations entre lesdifférents outils. C‟est dans une organisation de flux tirés que le TMS va déployer toute savaleur ajoutée, puisque dans ce cas, il va ordonnancer les flux transport avant d‟envoyer lapréparation des commandes, en fonction de ses besoins optimisés. Cependant, ce mode defonctionnement n‟est pas toujours possible, notamment dans un contexte de contraintes fortesd‟horaires de livraison. On voit ainsi que la mise en place d‟un TMS peut être lourd deconséquences sur l‟organisation globale de la chaîne logistique et qu‟il faut analyserl‟ensemble des impacts, avant de retenir le choix d‟organisation cible.Projet de Fin d‟études 2010-2011 76
  • 76. AnnexesEnfin, un troisième critère sur lequel il faut être très précis, c‟est la couverture fonctionnelledu TMS recherchée, en particulier quelles sont les fonctions « incontournables » que doitcouvrir le TMS ? Assistance à la mise en tournée, préfacturation / facturation, suivi et retourd‟informations clients, achat transport, suivi de l‟impact environnemental… Compte tenu dufaible taux de maturité des offres TMS, qui sont en plein développement, il faut s‟attacher àdéfinir les besoins fonctionnels requis à un niveau très détaillé. Par exemple, en ce quiconcerne l‟affectation des transporteurs à une tournée, il faut pouvoir donner l‟ordre depriorisation souhaité par le métier : meilleur coût ? Meilleur prestataire en fonction d‟unindicateur qualité ? Réutilisation du véhicule ? Saturation du véhicule ?… Tout en respectantles contraintes de livraison : horaires de livraison, contraintes d‟accès, typologie de véhiculerequis…Le risque, si l‟on ne descend pas à ce niveau de détail dans la grille fonctionnelle qui estgénéralement transmise aux éditeurs, est de recevoir un même niveau de réponses généralesdes éditeurs, qui ne facilitera pas une présélection. À l‟issue de cette phase, on est en mesurede rédiger un cahier des charges précisant l‟expression des besoins, ainsi qu‟une grille dequestions fonctionnelles détaillée.2.3.2 Phase de sélectionIl sera ensuite établi un « short list » d‟éditeurs dont les offres se rapprochent le plus desbesoins exprimés. Avec cette liste restreinte d‟éditeurs, nous recommandons ensuite de faireune maquette sur la base de données réelles d‟exploitation, ainsi que de visiter quelquesréférences clients sur lesquelles l‟outil est installé, afin de rentrer dans le détail despropositions des éditeurs. Cette phase de maquette et de visite est primordiale car elle permetd‟approcher la solution de manière un peu plus concrète et de vérifier ainsi son adéquation parrapport aux besoins. Après cette phase de sélection, qui dure entre 2 et 3 mois, les critères dechoix de l‟outil vont porter sur les éléments suivants :- étendue de la couverture fonctionnelle par rapport aux besoins (- Couverture des exigencestechniques.- Axes d‟amélioration de la solutionProjet de Fin d‟études 2010-2011 77
  • 77. Annexes- Niveau de paramétrage.- Ergonomie (simplicité d‟utilisation, navigation intuitive entre les différents écrans,adaptation des écrans aux utilisateurs…).- Solidité de l‟éditeur (solidité financière mais aussi capacité des équipes à mettre en œuvre lasolution).- Capacité de l‟éditeur à mettre en place la solution dans les délais exigés- Retour sur investissement de la mise en place de la solution : « par rapport à la couverturedes besoins, et à la tactique d‟investissement (acquisition de licences ou SaaS) quel est leretour sur investissement auquel l‟entreprise peut prétendre ? »2.3.3 Phase d’implémentationUn facteur clé de la réussite de l‟implémentation d‟un projet TMS, qui dure en général entre 8à 10 mois dans le cas d‟une organisation multi sites, se situe dans la constitution de l‟équipeprojet, qui doit intégrer des populations diverses :- opérationnels transports ayant une bonne connaissance des pratiques actuelles mais aussi dela cible envisagée,- équipe DSI (selon le mode d‟installation retenu).Cette équipe devra être enrichie à chaque fois que nécessaire d‟éclairage en provenance desautres secteurs impactés comme les fonctions entrepôt, achat, la gestion commerciale…Il ne faut pas négliger l‟importance du travail de collecte d‟informations en interne (tarifs,contraintes d‟exploitation, documents à émettre…) auprès des différents sites géographiquesou services. Il est préférable de faire ce travail, en amont des groupes de travail prévus avecl‟éditeur, afin d‟avoir déjà une vision d‟ensemble des processus transports actuels, desprocessus transports cibles et d‟avoir éventuellement déjà tranché en interne sur les éventuelsarbitrages liés aux processus cibles.Une fois cette phase achevée, le travail de « construction » avec l‟éditeur va pouvoircommencer en faisant dans le détail des fonctionnalités l‟adéquation entre besoins etparamétrages dans le système.C‟est une étape majeure de la mise en place dans le sens où les outils étant paramétrables àsouhait, il faut retenir les meilleurs choix d‟adéquation en privilégiant :- le moins de paramétrages possible (et donc le moins de maintenance),- le plus ergonomique pour l‟utilisateur final.Cette étape a également son importance car c‟est là que l‟on va définir les liens entre le TMSet les autres outils ou projets organisationnels de l‟entreprise.Projet de Fin d‟études 2010-2011 78
  • 78. AnnexesLes points de vigilance à ce stade du projet sont :- Ne pas tenter de faire rentrer coûte que coûte tous les cas d‟exploitation transport possibleset imaginables : se restreindre à faire en sorte que l‟outil traite les opérations les plusfréquentes qui représentent la majorité de l‟activité. Cela évitera d‟imaginer des solutions tropcomplexes qui génèrent bien souvent des développements et peuvent même aller à l‟encontredu bon fonctionnement de l‟outil.- Veiller à ce que la mise en place du TMS s‟harmonise dans l‟urbanisme des Systèmesd‟Information de l‟entreprise (ERP, WMS…) en s‟assurant notamment du non redondance detâches dans plusieurs outils.- Recenser et répertorier tous les axes de paramétrage de l‟outil, de manière à constituer unguide du paramétrage qui facilitera la phase de recette et permettra la maintenanceopérationnelle de l‟outil.2.3.4 Phase de migration et d’accompagnement au changementUne remise en cause de l‟organisation actuelle de l‟entreprise s‟avère nécessaire pour la miseen place d‟un TMS. Il faut préparer comme il se doit ce tournant dans l‟entreprise, enintégrant et en informant dès le début du projet les utilisateurs finaux de manière à ce qu‟ilss‟approprient leur nouvel outil. La plupart des outils offrent généralement la possibilitéd‟adapter les écrans à l‟utilisateur final : choix des informations à présenter dans un écran,ordonnancement de celles-ci, mise en évidence d‟informations par des codes couleur. Il estimportant de « construire » avec eux les écrans de travail des différents utilisateurs finaux,afin de les adapter aux besoins de chacun mais aussi de les alléger de manière à ce qu‟ils aientaccès aux seules informations utiles.Dans un contexte de grande diversité des solutions TMS, alors que les métiers impactés sonttrès spécifiques et complexes, le projet de mise en place d‟un TMS doit être un projetextrêmement cadré et structuré. Il ne faut pas perdre de vue que la mise en place d‟un TMSpeut remettre en cause l‟organisation logistique de l‟entreprise. La technicité du sujet ainsique la faible maturité des outils dans ce domaine nécessitent d‟aller dans un grand niveau dedétail des spécifications techniques.Enfin, le paramétrage, souvent, très ouvert, nécessite de faire des arbitrages en gardant unevision métier. Toutes ces raisons nous poussent à recommander aux entreprises de se faireaccompagner par une Assistance à Maîtrise d‟Ouvrage (AMOA) dont le rôle est de veiller àce que le projet soit piloté par les exigences métiers et non par des contraintes liées à l‟outil.Cette AMOA doit avoir un niveau d‟expertise très significatif dans les problématiquesTransport. Cela nous paraît être un gage de réussite. Ainsi, une équipe réunissant desopérationnels métiers, des représentants DSI, mais aussi des experts logistiques, qui pourrontapporter leur retour d‟expérience, aura toutes les compétences requises pour ce type de projetqui, au-delà du projet informatique est un projet technique et opérationnel.Projet de Fin d‟études 2010-2011 79
  • 79. AnnexesSynthèse :Il est indispensable de connaître les besoins de son entreprise pour investir dans un TMS.Comme on a pu le constater dans les exemples précédents les options des TMS sont plus oumoins complexes et il convient de savoir lesquelles seront utiles. Si une entreprise possèdedéjà des logiciels performants dans des domaines comme la comptabilité ou les ressourceshumaines qui ont nécessités du temps pour les mettre en œuvre et former le personnel, il estalors inutile de les remplacer par une offre complète d‟un éditeur. Bien évidemment si celogiciel gère parfaitement la partie transport de votre entreprise, un TMS est inutile ! Lepremier critère de choix se situe donc entre une solution complète ou « modulable» selon lebesoin de l‟entreprise.2.4 PERSPECTIVES D’EVOLUTION DES TMS2.4.1 Un marché très segmentéGlobalement, on peut deviser le marché en trois grands domaines : les chargeurs, lesorganisateurs de transport (3PL, 4PL et transitaires) dont la logique se rapproche de celle desindustriels et les prestataires logistiques avec les transporteurs. À l‟intérieur de ces grandescatégories, on peut également opérer une segmentation client. Ainsi, les prestataireslogistiques se composent de grands acteurs internationaux, type DHL, Schenker, ou Gefco, degrosses PME et de structures nationales, voire régionales. Selon ces segments, les produitspeuvent être relativement différents pour s‟adapter aux besoins des clients et à la taille del‟entreprise.2.4.2 Le mode SaaS (Software as a Service)Souple, modulable et réversible, la location d‟applications hébergées présente des avantagesdécisifs par rapport au modèle classique de licences : réduction des coûts, facilité dedéploiement, gains de temps pour les équipes informatiques en interne. Les progiciels SaaSrépondent désormais à presque tous les besoins des entreprises, même complexes. Pourpreuve, SAP vient par exemple de racheter Coghead, une start up qui commercialise un ERPen mode SaaS. Les WMS et TMS suivront obligatoirement cette tendance, certains ayant déjàcommencé.2.4.3 Renforcer l’intégration entre ERP, WMS et TMSLes éditeurs de WMS et de TMS entendent renforcer l‟intégration de leurs solutions etdévelopper les complémentarités de chacune. Aujourd‟hui, entrepôts et transports sont encoresouvent gérés par des familles de produits distinctes. Pourtant un responsable logistique peutcumuler les deux fonctions et de son point de vue, l‟optimisation d‟un entrepôt ou d‟uncamion relève de la même logique : traçabilité des marchandises, optimisation du métrageplancher et du volume d‟entreposage… En tant que manager des activités logistiques, il doitpouvoir mesurer la rentabilité des transporteurs comme celle des manutentionnaires. LesProjet de Fin d‟études 2010-2011 80
  • 80. Annexesindicateurs de performance doivent puiser indifféremment dans les données statistiques dessolutions TMS et WMS. Mais la redondance des informations fournies par les superviseursd‟activité de chacune de ces solutions peut gêner ou biaiser sa vision d‟ensemble des activitéslogistiques. Les projets logistiques sont donc de plus en plus décloisonnés. En renforçant lescomplémentarités fonctionnelles des deux solutions, c‟est un pilotage plus fin et plus agile dela Supply Chain Execution qui est proposé. Concrètement, l‟organisation du transport, dansune solution WMS s‟appuie sur les données de dimensionnement des marchandises,impactant les opérations de chargement, le choix du mode de transport et du transporteur etl‟organisation du transport. Ces fonctions sont prises en compte, dans une solution WMS.Mais un TMS permet en plus de cela, de piloter les flux internationaux, multimodaux et detracer les flux financiers liés à ces opérations. Si la complexité ou le volume des flux l‟exige,la gestion des expéditions classiques, messagerie ou express, d‟une part, et de cellesnécessitant un appel d‟offres, d‟autre part, peut être répartie plus efficacement entre le WMSet le TMS, en s‟appuyant sur les complémentarités de chaque solution. Les gains sontmultiples tant sur le plan de l‟entreposage et de la préparation de commandes que dutransport. L‟économie potentielle sur les coûts d‟exploitation varie de 15 à 30 % selon leséditeurs DDS Logistics et Hardis. La même source indique que la réduction des stockstampons induite par un pilotage fiable de la Supply Chain et un système d‟alertes performantgénèrent des gains sur le coût financier du stock qui peuvent varier de 1 à 10 jours de rotation.2.4.4 La collaboration entre les acteurs logistiquesLes solutions futures pour la logique collaborative seront basées sur des architectures qui sesitueront entre deux logiques extrêmes : solution intégrée et réseau d‟outils simples, à base deTIC, mais à forte capacité de communication et d‟apprentissage entre les acteurs.Facilitant la collaboration et le partage d‟informations entre les acteurs de la chaîne logistique,les logiciels TMS proposent en plus un portail web comportant une fonctionnalité detéléchargement de documents (connaissement, liste de colisage, douanes).De leur côté les WMS proposent des fonctionnalités de traçabilité multimodale globale, c‟està dire capables d‟inclure l‟ensemble des tiers de la chaîne logistique.2.4.5 Une architecture ouverteAinsi, les progiciels de TMS opèrent au niveau de l‟exécution dans la Supply Chain et doiventêtre extrêmement ouverts afin de s‟intégrer parfaitement dans un système d‟informationglobal : ERP, WMS, logiciels spécifiques… À ce titre, le choix des plates-formes dedéveloppement et d‟hébergement est primordial.Benchmarking des solutions TMS Si nous prenons l‟exemple de la France seulement 20% des entreprises françaises fontappel au TMS (Transport Management System) pour la gestion de leur fonction transport.Projet de Fin d‟études 2010-2011 81
  • 81. AnnexesPourtant, cet outil informatique de gestion peut générer des économies de 10 à 15% du coûtdu transport. Dans cette partie on va comparer des solutions TMS en termes de fonctionnalités, touten citant ses secteurs d‟activité, les modes couverts, ainsi que les points forts de chaquesolution et ses différentes caractéristiques.Présentation des sociétés choisis : - ORACLE Leader mondial des solutions de e-business, Oracle Corporation est le premier fournisseurmondial de logiciels pour la gestion d‟information, et le numéro deux mondial du logiciel.Avec un chiffre d‟affaires de plus de 10,9 milliards de dollars, Oracle propose ses bases dedonnées, outils et progiciels applicatifs, ainsi que les services associés de conseil, deformation et de support, dans plus de 145 pays à travers le monde. - SAGE Sage propose Sage Transport qui est une solution progicielle complète dédiée auxprestataires de transport. Cette solution comporte de nombreuses fonctionnalités présentéesdans divers modules dédiées ou intégrées. Ainsi, Sage TRANSPORT se complète par cesmodules de gestion pour répondre aux besoins de réglementation et d‟évolution des activitésdes transporteurs routiers : gestion d‟entrepôts, traçabilité, pilotage décisionnel, services dedédouanement, messagerie...Projet de Fin d‟études 2010-2011 82
  • 82. AnnexesSociété Nom de la Secteurs Modes S’adresse Fonctions gérés Regroupement/ affectation/ Documents solution d’activité couverts aux optimisation produitsORACLE Oracle Industrie Aérien Chargeurs -La planification du Regroupement : Manuel / - Récapitulatif des Transportation transport automatique/ guidé BL Prestataire Maritime Transporteurs - Liste de colisage Management -L‟ordonnancement logistique quotidien Critère d’affectation : trajet, - Lettre de voiture Fluvial Commissionn - Confirmation -Le suivi en temps respect du délai de livraison, coût Grande -aires d‟affrètement Ferroviaire réel de l‟exécution minimal, contraintes véhicules, distribution fiabilité transporteur, capacité. - Pro-forma des ordres de Import/export Routier transport Optimise : les chargements, les intermodal -Gestion de la base quais tarifaire achat de transport Traçabilité temps réel : -Gestion des appels marchandises, containers, véhicules d‟offres -Mesure des critères fournisseurs Projet de Fin d‟études 2010-2011 83
  • 83. AnnexesSage Eurotrans XPR Transport Fluvial Transporteurs - Suivi de flotte, Regroupement : Manuel / - plan de chargement routier de Ferroviaire calcul de distance, automatique/ guidé. marchandises - récapitulatif des BL routier calcul de temps de Pas d’affectation conduite - liste de colisage - la planification du Traçabilité temps réel : des transport - lettre de voiture marchandises, des containers, des - l‟ordonnancement véhicules, des étapes de traitement - confirmation quotidien des ordres de transport d‟affrètement - le suivi temps réel de l‟exécution des Optimise : les tournées de collecte - pro-forma ordres de transport via interface avec différents - L‟exploitation Partenaires, les tournées de assistée par distribution via interface avec ordinateur différents PartenairesSage Commissionnai Commissio- Fluvial Commissionn - Suivi de flotte Regroupement : Manuel / plan de chargement -re XPR nnaires -aires - Calcul de distance, automatique/ guidé. Ferroviaire - récapitulatif des BL - Calcul de temps de Critère d’affectation : - trajet de transport routier conduite - respect du délai de livraison - liste de colisage - la planification du - coût minimal transport - contraintes véhicule - lettre de voiture - l‟ordonnancement - fiabilité transporteur - confirmation quotidien - La qualité des transports d‟affrètement - le suivi temps réel déjà effectué de l‟exécution des optimise : - les tournées de collecte - pro-forma ordres de transport - les tournées de distributionProjet de Fin d‟études 2010-2011 84
  • 84. AnnexesSage elit Inter Commissionn aérien transporteurs - la planification du Regroupement : Manuel / - plan de chargement aires de transport international maritime transport automatique/ guidé. - récapitulatif des BL - Transitaires et fluvial commissionn Affectation : - trajet - liste de colisage Commissionnaire ferroviaire -aires - l‟ordonnancement - respect du délai de livraison - lettre de voiture s en Douane -organisateurs de routier quotidien - coût minimal - confirmation Fret maritime, intermodal Organisateurs - fiabilité transporteur d‟affrètement aérien et de transport - le suivi temps réel - pro-forma multimodal, internationaux de l‟exécution Pas d’optimisation - import/export groupeurs internationaux des ordres de - déclaration transport douanes - documents de transport pour d‟autres modes (aérien, maritime…)Projet de Fin d‟études 2010-2011 85
  • 85. Annexes Annexe 3 : UML & ARIS UMLUML est un langage qui définit un ensemble de notations graphiques et leurs sémantiques. Néen 1994 de la fusion des méthodes objets dominantes (OMT crée par James Rambaugh etBooch crée par Grady Booch et OOSE crée par Ivar Jacobson), puis normalisé par l‟OMG en1997. Il est devenu un standard incontournable.UML est un langage de modélisation unifié favorisant :  Une meilleure communication entre les intervenants dans un projet, puisque UML offre des moyens de captures des connaissances sur un sujet à travers divers points de vues (ces points de vues sont fournis par les différents diagrammes de UML).  Une bonne compréhension du problème, en fait le système à étudier sera traité suivant différents angles et les différents cas d‟utilisation de ce système.  UML incorpore les meilleures pratiques d‟ingénierie dans les différents domaines qui ont abouti à son apparition. Ce qui lui permet d‟être adapté aux différents types de systèmes.UML permet aussi de suivre un projet dans ses différentes étapes :  Spécifier : UML s‟adresse à la spécification du système, il peut être utilisé pour modéliser les besoins (le quoi) et l‟architecture (le comment).  Visualiser : les différents diagrammes donnent aux concepteurs une vue précise sur le système avant sa réalisation.  Construire : les différents diagrammes et modèles établis durant la phase de spécification et de conception, servent de base pour la réalisation.  Documenter : les diagrammes utilisés durant les différentes phases pour communiquer les connaissances entre les membres du projet, de la spécification des besoins jusqu‟à la réalisation, présentent un document détaillé sur les diverses phases et modules du projet. Diagrammes UMLUML définit neuf diagrammes :  Diagrammes d‟activités : représentent le comportement d‟une opération en termes d‟actionsProjet de Fin d‟études 2010-2011 86
  • 86. Annexes  Diagrammes des cas d‟utilisation : représentent les fonctions du système de point de vue de l‟utilisateur  Diagrammes de classes : représentent la structure statique en termes de classes et de relations  Diagrammes de collaboration qui sont une représentation spatiale des objets, des liens et des interactions  Diagrammes de composants : représentent les composants physiques de l‟application  Diagrammes de déploiement : représentent le déploiement des composants sur les dispositifs matériels  Diagrammes détats transitions : représentent le comportement d‟une classe en terme d‟états  Diagrammes dobjets : représentent les objets et leurs relations. Ils correspondent à des diagrammes de collaborations simplifiés, sans représentation des envois de messages  Diagrammes de séquences qui sont une représentation temporelle des objets et de leurs interactions Architecture de système d’informations intégrées (ARIS)La conception de lArchitecture de Systèmes dInformation Intégrés (ARIS) repose sur unconcept dintégration dicté par une vision globale des processus de lentreprise. La conceptionde larchitecture se base tout dabord sur un modèle développé pour les processus dentrepriseet contenant toutes les caractéristiques principales nécessaires à la description de processusdentreprise. Le modèle complexe qui en résulte est décomposé en plusieurs vues. Cettedécomposition par vues permet alors de procéder à la description du contenu de ces vues àlaide de méthodes spécialement adaptées à chacune delles sans quil soit nécessaire de tenircompte des multiples relations et liens que ces vues peuvent entretenir entre elles. Lesrelations entre les vues sont ensuite prises en compte et regroupées sans redondances pour unevue générale des chaînes de processus.La deuxième étape permettant de réduire la complexité de larchitecture consiste à distinguerdifférents niveaux descriptifs. Les diverses méthodes descriptives appliquées aux systèmesdinformation sont classées selon un concept Life Cycle en fonction de leur degré derapprochement avec les techniques de traitement de linformation. Ceci permet dobtenir unedescription approfondie de tous les aspects, depuis la problématique de gestion dentreprisejusquà la transposition technique. Le concept ARIS fournit ainsi un cadre dans lequel dessystèmes dinformation intégrés peuvent être développés et optimisés et dans lequel laProjet de Fin d‟études 2010-2011 87
  • 87. Annexestransposition de ces systèmes peut être décrite. Cest en particulier limportance du niveaudescriptif spécialisé qui permet au concept ARIS de jouer un rôle dorientation lors delélaboration, de lanalyse et de lévaluation de chaînes de processus économiques. Unedescription plus précise de larchitecture de systèmes dinformation intégrés est fournie parScheer.Les composants requis pour la description complète dun processus dentreprise sont lesopérations, les événements, les prestations (états), les utilisateurs, les unités organisationnelleset les ressources des techniques de traitement de linformation. Si tous les effets sur tous leséléments du processus devaient être pris en compte pour chaque opération observée, lemodèle serait extrêmement complexe et la description serait redondante.ARIS dispose de cinq vues : o Vue de gestion :Lenchaînement de fonctions au sens dun processus dentreprise est représenté dans deschaînes de processus.Dans ces chaînes, il est possible dindiquer les événements de départ et darrivée pour chaquefonction. Les événements déclenchent les fonctions et sont le résultat de ces dernières.Le symbole graphique de lévénement est un hexagone. La désignation dun événement doitcomprendre à la fois lobjet dinformation (commande) et le changement détat de cet objet(est arrivée). Vue des fonctionsLes méthodes de modélisation considèrent souvent les fonctions par rapport aux objets desautres vues descriptives dARIS. Ainsi, par exemple, le lien entre les données et les fonctionsest représenté pour spécifier le processus de transformation dune fonction par les donnéesInput/Output de la fonction. Dans larchitecture ARIS, on observe toutefois une séparationstricte entre les champs dobservation. Ainsi, au sein de la vue des fonctions, seuls les moyensProjet de Fin d‟études 2010-2011 88
  • 88. Annexesde représentation qui présentent une liaison entre les fonctions sont traités. Les liaisons entreles fonctions et les données sont par ex. représentées dans la vue de gestion dARIS. Vue des donnéesLes règles de gestion de la vue des données contiennent la description du modèle de donnéessémantique du domaine de recherche concerné. Selon le principe de décomposition dARIS,les objets permettant la spécification des événements de départ et de fin, ainsi que lesdescriptions détat du cadre pertinent dune chaîne de processus, sont décrits.Par rapport à la modélisation de fonctions, la modélisation de données est très exigeante dupoint de vue de la méthode. Dans la vue de fonction, un seul objet, la fonction, est pris encompte. En outre, seuls les ordres inférieurs et supérieurs sont représentés comme relationsentre les fonctions. Vue organisationnelleLorganisation structurelle rassemble les règles relatives à la structuration statique delentreprise. Lorganisation opérationnelle comprend les règles relatives aux tâches à exécuterpar lentreprise. Cette structure relative aux tâches dans loptique dune répartition de fonctionssur les responsables des tâches est traitée dans la vue de gestion de la Maison ARIS. La vueorganisationnelle comprend ainsi essentiellement la représentation de la configuration delorganisation structurelle.Projet de Fin d‟études 2010-2011 89