Rapport de projet de fin d étude Développement d un MRP à capacité finie pour l ERP libre OfbizNéogia

Transcription

1 Université François Rabelais Tours École Polythechnique Universitaire - Département Informatique 64, avenue Jean Portalis Tours Rapport de projet de fin d étude Développement d un MRP à capacité finie pour l ERP libre OfbizNéogia Encadrants : Étudiant : SOUKHAL Ameur GORON Peter HEINTZ Olivier EPU-DI 3 e année Année

2 Table des matières I Environnement technique du projet 3 1 Présentation d Ofbiz Une architecture Un framework L Entity Engine Le Service Engine Le Control Servlet Des applications Présentation de Néogia Les enjeux de la génération de code Les applications Néogia II État de l art 12 3 Planification de la production Présentation des systèmes MRP Historique Pré-requis pour la mise en oeuvre d un MRP La logique du MRP Défauts des systèmes MRP Planification des capacités de production Planification des besoins en moyens de production Principe Mise en oeuvre Validation du plan directeur de production Approche par facteurs globaux Approche par feuille de capacité Approche par profil de ressource Planification des besoins en capacité de production Calcul de la charge Résultats du CRP Techniques de lissage de charge Lissage en parallèle Lissage en série Limitations Conclusion de l état de l art 26 III Analyse de l existant 27 7 Étude du MRP existant Données manipulées par le MRP ii

3 7.2 Fonctionnalités Particularités Module de gestion de production Gestion des données techniques Les ressources Le calendrier industriel Les gammes opératoires Les opérations Les nomenclatures Gestion d atelier Les ordres de fabrication Programmation de la production IV Développements réalisés 35 9 Solution mise en oeuvre Présentation de la solution Principe Place du décideur Algorithme de lissage en série simplifié Analyse des besoins fonctionnels MRP CRP Développement du MRP Modélisation du MRP Les entrées Les sorties Structures de contrôle du MRP Algorithmes mis en oeuvre Algorithme du MRP mono-article mono-niveau Algorithme du MRP mono-article multi-niveaux Algorithme du MRP multi-articles Intégration dans OfbizNéogia Services du MRP Interfaces graphiques du MRP Développement du CRP Structures de données du CRP Gestion de plannings Modélisation des capacités d une ressource Modélisation des charges d une resources Algorithmes de planification Algorithme de planification d un OF Algorithme de planification d une opération Algorithme de planification de l utilisation d une ressource Conséquences de la planification à capacité finie Intégration avec le module de gestion d atelier iii

4 V Bilan Bilan du projet État d avancement Problèmes rencontrés Problèmes fonctionnels Problèmes techniques Temps de développement Améliorations possibles Conclusion 67 VI Annexes 68 A Modélisation des données techniques dans OfbizNeogia 69 B Modélisation des ordre de fabrication dans OfbizNeogia 70 C Modélisation du MRP réalisé 71 D Modélisation des charges/capacités des ressources 72 Glossaire 74 Bibliographie 75 iv

5 v

6 Remerciements Mes remerciements s adressent en premier lieu à Ameur SOUKHAL et Olivier Heintz pour leur disponibilité et pour m avoir laissé une trés grande autonomie pour mener ce projet. Je souhaiterais aussi remercier toute l équipe Néréide pour leur collaboration sur ce projet. 1

7 Introduction Ce projet, en collaboration avec la société Néréide, porte sur la réalisation d un MRP (Material Requirements Planning) à capacité finie pour l ERP (Enterprise Resource Planning) libre OfbizNéogia. Il s inscrit dans la continuité d un projet de fin d étude réalisé en 2004 par Thierry Grauss, qui portait sur la réalisation d un MRP à capacité infinie. Néréide est une jeune société de services en logiciels libres, spécialisée dans l intégration de progiciels de gestion. L objectif de ce projet est donc d ajouter au MRP de son progiciel, OfbizNéogia, la prise en compte des capacités de production lors de la planification des besoins en composants. Cette prise en compte des capacités est particulièrement importante pour assurer que les délais de livraison seront respectés par la planification proposée par le MRP. Ce rapport se divise en cinq parties. La première présente l environnement technique dans lequel s est effectué ce projet. La seconde est un état de l art sur les MRP et les problèmes de gestion de capacité de production, elle permet ainsi de situer la problématique du projet et les différentes solutions envisageables. La troisième partie est une étude de l existant, c est-à-dire une étude des bases à partir desquelles les développements doivent prendre lieu. Puis la suivante présentera la solution mise en oeuvre et les développements réalisés pour mener ce projet à son terme. Enfin la dernière partie porte sur le bilan du projet, aussi bien sur l adéquation des résultats par rapport aux objectifs que sur les acquis. 2

8 Première partie Environnement technique du projet 3

9 Chapitre 1 Présentation d Ofbiz Open For Business, ou Ofbiz, est un projet de progiciel de gestion intégré (PGI) libre initié par deux développeurs américains, Andy Zeneski et David E. Jones, en mai L objectif de ce projet est de fournir un ensemble de composants homogènes permettant de développer aisément et rapidement des logiciels libres de gestion. À terme, il est prévu d obtenir tous les composants nécesssaires à un PGI intégrant les modules de gestion suivants : un ERP (Enterprise Resource Planning) ; un SCM (Supply Chain Management) ; un CRM (Customer Relationship Management) ; un MRP (Manufacturing Resource Planning) ; un CMS (Content Management System) ; un CMMS (Computerized Maintenance Management System) ; et une plateforme d ebusiness / ecommerce ; Pour atteindre ces objectifs, Ofbiz se base sur de nombreux logiciels libres tels que Subversion, ant, Tomcat, JPublish, FreeMarker, etc. Ces logiciels sont reconnus pour leur qualité et ils assurent l indépendance du projet. De même, Ofbiz respecte de nombreux standards pour garantir un maximum de compatibilité avec les systèmes existants et futurs, notamment J2EE et XML. Ce dernier est largement utilisé dans tout le projet pour décrire les données et les traitements. Par ailleurs, le code source du projet est publié sous la licence MIT qui est libre et permissive, c est-à-dire qu elle ne fixe aucune obligation et/ou interdiction quant à l utilisation, la modification, l extension et la commercialisation du logiciel. Grâce à l ouverture du code, une véritable communauté d utilisateurs et de développeurs s est formée. Cette dernière assure ainsi la réactivité et la qualité du projet. Cependant, de par sa taille et sa complexité, ce type de logiciel nécessite de gros investissements humains, matériels et financiers pour son développement mais aussi pour être reconnu. Les auteurs initiaux ont donc créé une société, Undersun Consulting, qui offre des services autour d Ofbiz tout en les rémunérant pour leur travail de développement. Plusieurs sociétés du même type se sont créées un peu partout dans le monde dont Néréide pour la France. Elles participent 4

10 1.1. UNE ARCHITECTURE ainsi au projet en tant que sponsors. Généralement, ces sociétés proposent quatre types de services : l installation et l adaptation si nécessaire d Ofbiz ; le développement d extensions spécifiques à l entreprise ; la maintenance du système ; la formation des utilisateurs. 1.1 Une architecture Ofbiz est une application java client-serveur compatible avec la spécification J2EE qui définit une architecture logicielle standard. On retrouve ainsi les trois éléments caractéristiques d une architecture 3-tiers : les clients : ici des clients légers, typiquement des machines peu puissantes disposant d un navigateur internet ; un serveur exécutant les différentes applications Ofbiz ; et une ou plusieurs bases de données stockant le système d information de l entreprise. Fig. 1.1 Architecture n-tiers d Ofbiz Néanmoins, l architecture d Ofbiz peut aussi être considéré comme une architecture n-tiers car elle peut faire appel à des applications externes via des services. Ces derniers ne sont pas forcément exécutés sur la même machine, on les appelle alors WebServices. Ce type d architecture présente de nombreux avantages. Elle permet de distribuer plus librement la logique applicative, ce qui facilite la répartition de la charge entre tous les niveaux. Elle facilite l intégration de l application avec celles déjà existantes. Enfin, elle permet d accéder à un très grand nombre de fonctionnalités. Fig. 1.2 Architecture J2EE d Ofbiz Une des caractéristiques principales d Ofbiz est la modularité de son architecture. En effet, tout est composant. Cette approche favorise une meilleure réutilisation des composants logiciels, 5

11 1.2. UN FRAMEWORK un développement modulaire donc plus rapide et enfin une meilleure qualité. Ce type d architecture permet aussi de remplacer un composant par un autre très facilement dans le cas où il existe plusieurs implémentations différentes. Ofbiz se décompose en deux parties : le serveur et les composants. Le serveur, ou base, propose un environnement d exécution homogène et performant pour les applications qu il fait tourner. Il fournit tout un ensemble de mécanismes de gestion de cache et de pools de connexions qui permettent une meilleure montée en charge et une meilleure réactivité du système. Les composants, quant à eux, représentent les plus petites briques logicielles gérées par le serveur. Ils peuvent fournir un ensemble de ressources permettant de construire tout ou partie d une application Ofbiz. Ces ressources peuvent correspondre à : un jeu de données, un modèle de données, des services, une ou plusieurs applications web, du code java. Généralement, un composant est spécialisé pour une fonctionnalité donnée. L architecture d Ofbiz se décompose en une multitude de composants qui, regroupés ensemble, forment un PGI complet. Toutefois, tous n ont pas le même rôle au sein du PGI, c est pourquoi on les classe selon trois niveaux d abstraction : le framework qui permet de développer des applications métier rapidement ; les applications de base que l on retrouve dans tout type d organisation ; les applications de haut-niveau et/ou applications métier. 1.2 Un framework Ofbiz est en premier lieu un «framework d application d entreprise» dans lequel chaque composant représente une brique logicielle pouvant être réutilisée pour construire des applications diverses. Ce framework repose sur trois composants essentiels sans lesquels une application standard ne pourrait pas fonctionner : l Entity Engine, le Service Engine et le ControlServlet L Entity Engine L Entity Engine est un composant Ofbiz qui se charge de la gestion des données de tous les autres composants Ofbiz. Les données sont représentées selon un modèle Entité-Relation largement utilisé dans les applications d entreprise et compatible avec la plupart des bases de données relationnelles. Le principal objectif de ce composant est d éliminer tout code spécifique à la persistance des données dans un système transactionnel. Ses principales caractéristiques sont : accès aux données via une interface unique, le «GenericDelegator» ; supporte l accès transparent à plusieurs base de données ; les entités sont définies dans de simples fichiers XML ; tous les types java de base ont un équivalent en base de données ; supporte les transactions distribuées ; suppporte un mécanisme de trigger appelé «EECA 1» même si le SGBD sous-jacent n implémente pas cette fonctionnalité. 1 Entity Event-Condition-Action 6

12 1.2. UN FRAMEWORK Le Service Engine Le Service Engine est l équivalent de l Entity Engine pour tous les traitements des composants Ofbiz. Les traitements sont appelés Services et peuvent être exécutés localement ou à distance. Le principal intérêt de ce composant est qu il permet de lancer des services sans avoir besoin de connaître leur localisation et leur implémentation. C est le ServiceDispatcher qui se charge alors de trouver l implémentation du service et de son exécution. Un autre intérêt est la possibilité de rendre disponible tout service Ofbiz vers l extérieur. Les services sont définis dans des fichiers XML dans lesquels il faut indiquer pour chaque service : son nom ; son implémentation (java, beanshell, minilang, etc) ; sa localisation ; la méthode à invoquer lors de son appel ; la nécessité ou non d être authentifié pour pouvoir l appeler ; ses paramètres d entrée ; ses paramètres de sortie. Un service est un traitement qui prend des paramètres en entrée et des paramètres en sortie. Ces paramètres sont vérifiés avant et après l appel d un service. Le traitement peut être asynchrone ou synchrone. L accès aux entités à partir d un service se fait automatiquement par l intermédiaire d une transaction ainsi en cas d échec du service, la cohérence des bases de données est conservée Le Control Servlet Le ControlServlet est l élément clé de la communication entre les utilisateurs et les applications web d Ofbiz. Implémenté selon le modèle MVC (Modèle-Vue-Controleur), il gère la boucle d évènements de l interface graphique et les différents moteurs de rendu de l application. Les réponses aux intéractions de l utilisateur s effectuent par l intermédiaire d évènements qui peuvent être implémentés sous la forme de services, de méthodes java, de scripts Beanshell ou Minilang. Voici l ensemble des opérations effectuées suite à une intéraction avec l utilisateur pour lui afficher une page à l aide de JPusblish et FreeMarker (cf. Figure 1.3) : 1 L utilisateur clique sur un lien hypertexte ou valide un formulaire. Le navigateur envoie alors une requête HTTP au serveur Ofbiz qui est interceptée par Tomcat et transmise au ControlServlet de l application web correspondante. 2 Le ControlServlet vérifie si l URI demandée est définie par l application. Le cas échéant, il appelle le ou les événements associés à cette URI. Dans le cas contraire, il renvoie une erreur au navigateur web de l utilisateur (Erreur HTTP 404 : page non trouvée). 3 Si l évènement généré doit appeler un service, il vérifie que les paramètres de la requête correspondent aux attributs du service. 4 Si l évènement généré doit appeler un service, il convertit les paramètres de la requête sous forme textuelle en objets Java correspondant. 5 L évènement appelle un service ou un gestionnaire d évènements (méthode java statique). 6 Le service ou le gestionnaire d évènements peuvent effectuer des actions sur le modèle de données. 7

13 1.3. DES APPLICATIONS Fig. 1.3 Boucle d évènement d une application Ofbiz 7 L EntityEngine convertit ces actions en requêtes SQL pour le serveur de base de données. 8 Le service ou le gestionnaire d évènement renvoie le résultat de leur action. 9 L évènement transmet ce résultat au ControlServlet À partir du résultat de l évènement, le ControlServlet sélectionne la vue à afficher et appelle le moteur de rendu adéquat. À partir de la définition d une vue, le moteur de rendu construit les différents sous-éléments de cette dernière. 12 Pour chaque sous-élément, il peut appeler des scripts BeanShell qui récupèrent et mettent en forme les données à afficher. 13 Pour chaque sous-élément, il appelle le moteur de template qui se charge de générer le code HTML correspondant. 14 Le moteur de rendu assemble les différents sous-éléments pour former une page web complète. 15 Le ControlServlet transmet la page générée au navigateur web de l utilisateur. 1.3 Des applications Un des avantages d Ofbiz par rapport à d autres frameworks, est qu il fournit un certain nombre d applications par défaut, qui couvrent quasiment tous les domaines de l entreprise. Elles sont livrées prêtes à l emploi ; il ne reste plus qu à saisir les données spécifiques à l entreprise. On distingue deux types d application au sein d ofbiz : les applications de base que l on retrouve dans toute organisation et les applications haut-niveau et/ou métiers, spécifique à un secteur d activité. 8

14 Chapitre 2 Présentation de Néogia Bien qu Ofbiz soit un logiciel écrit en Java, ses auteurs ont privilégié une approche Entité- Relation plutôt qu une approche orientée objet pour la modélisation du système d information de l entreprise. Ce choix est motivé par un souci de simplicité et de généricité au niveau de la couche de persistence de données d Ofbiz (Entity Engine). Cependant, ce type de modélisation présente le problème de s attacher plus aux données qu à la dynamique du système. En conséquence, on est souvent amené à manipuler directement les tuples de la base de données ce qui peut poser des problèmes de cohérence et de duplication de code. De plus, cette approche ne permet pas d utiliser le haut niveau d abstraction qu offre le langage de programmation. Pour pallier cet inconvénient, Néréide a entrepris en mai 2004 le développement d un nouveau projet appelé Néogia, publié sous la licence GPL. L objectif de ce projet est de fournir à la communauté un ensemble d outils et d extensions permettant de développer des applications Ofbiz à l aide d une modélisation objet. Ces extensions se présentent sous la forme de composants Ofbiz générés à partir de diagrammes UML. Le temps gagné par la technique de génération de code employée dans Néogia permet aux développeurs de se consacrer principalement à la modélisation de leur application et donc d augmenter la qualité du produit final. Les outils de génération de code utilisés par le projet Néogia se basent sur une technologie mise au point par Code-Lutin, une société de services en logiciels libres nantaise, membre du réseau Libre-Entreprise et spécialisée dans le développement applicatif en Java. Cette technologie, appelée LutinGenerators, permet à partir d une modélisation UML stockée dans un fichier XMI 1 de générer n importe quel type de fichier dès l instant qu un générateur correspondant existe. L utilisation de cette technologie est le fruit d une collaboration entre Néréide et Code- Lutin dans le cadre d un transfert de compétences au sein du réseau Libre-Entreprise. 1 Format XML permettant l échange de modèles UML entre outils de développement logiciel. 9

15 2.1. LES ENJEUX DE LA GÉNÉRATION DE CODE 2.1 Les enjeux de la génération de code Les applications d un progiciel de gestion sont en général très complexes du fait du grand nombre de fonctionnalités développées et du volume de données très important à manipuler de façon sécurisée. Ceci implique un temps de développement très long. Or, les problématiques actuelles de conception de logiciels libres sont en totale oppposition. En effet, du fait du nombre réduit de développeurs, la conception d un logiciel libre nécessite de : limiter le temps de développement ; assurer la souplesse de la plateforme notamment lors d un changement de technologie ; limiter les efforts liés à la maintenance du code. Dans ce contexte, la génération de code qui consiste à automatiser la création du code dit d architecture, est un enjeu important pour les sociétés de services dans le logiciel libre. En effet, cela permet à la société de concentrer ses efforts non sur le codage d architecture qui ne sera pas source de valeur ajoutée mais sur la demande spécifique des clients qui quant à elle, sera génératrice de valeur ajoutée. Dans le cas de Néogia, les développements sont réalisées via une approche MDA (Model Driven Architecture) dans laquelle tout développement passe par la définition d un modèle UML qui sera ensuite utilisé pour générer le code de l application. Fig. 2.1 Schéma MDA utilisé par Néogia. Les générateurs de code de Néogia se chargent de créer toute la couche de persistance de données entre les objets issus de la modélisation et les entités gérées par l Entity Engine d Ofbiz, et de créer l interface graphique et les services associés. L intérêt des composants généré par Néogia par rapport aux composants Ofbiz est qu ils sont issus de diagrammes UML et que leur code est généré à 70 %. L un des reproches qui est souvent fait aux outils de génération de code est de ne pas pouvoir distinguer les éléments générés des éléments développés lors de générations successives. Les générateurs de Neogia ont été conçus pour éviter ce genre de cas en séparant les parties développées des parties générées. 10

16 2.2. LES APPLICATIONS NÉOGIA Voici quelques générateurs fournis par Néogia : générateur de services ; générateur d entités ; générateur de la couche d abstraction Objet-Entité ; générateur d interfaces graphiques par défaut pour les objets modélisés ; générateur des formulaires de recherche ; générateur des fichiers d internationalisation ; etc. 2.2 Les applications Néogia Afin de démontrer l efficacité de l approche MDA pour le développement d applications métiers pour Ofbiz, Néréide a recréé entièrement le module de gestion de production d Ofbiz via cette approche. Les résultats étant au rendez-vous, les applications de gestion des stocks et de comptabilité ont elles aussi été refaites. Par la suite, d autres composants d Ofbiz ont été partiellement porté sur cette nouvelle architecture pour faciliter l intégration des deux projets. La modélisation UML de ces applications à été realisée à partir de l expérience acquise lors de la mise en oeuvre d autres ERP et également à partir des retours d expérience de l utilisation d Ofbiz. Pour éviter des confusions entre les applications Ofbiz et les applications Néogia, l ERP a été renommer OfbizNéogia. 11

17 Deuxième partie État de l art 12

18 Chapitre 3 Planification de la production «La planification de la production vise, pour un horizon de planfication en général de quelques mois, à optimiser l utilisation des facteurs productifs disponibles pour la production d un ou plusieurs produits répondant à des caractéristiques précises. Il s agit d un processus de traitement d informations aboutissant à une programmation prévisionnelle s appuyant sur une démarche d optimisation.» Vincent Giard, [VG88]. En d autres termes, la planification de la production permet d une part d anticiper pour satisfaire la demande, de prévoir les approvisionnements, et de planifier l utilisation des moyens de production. D autre part, elle peut aussi être utilisée comme un moyen d optimiser la production en cherchant, par exemple, à minimiser les coûts tout en respectant les délais. Il existe différénts systèmes de planification de production : Planification hiérarchisée : méthode utilisée pour élaborer le plan directeur de production, les produits finis sont regroupés par type et par famille. Elle est adaptée aux productions de masse. (Hax et Meal, 1975) MRP : méthode utilisée pour déduire les besoins en composants à partir de la demande finale. C est un système à flux poussé. (J. Orlicky, 1975) OPT : méthode de planification traitant différemment les ressources goulots des ressources non-goulots. Elle ordonnance les ordres de fabrication sur les ressources limitées en priorité. (E. Goldratt, 1969) Kanban : cas particuliers par rapport aux autres méthodes car il n y a pas véritablement de planification. Le système de gestion de production s auto-régule en fonction de la demande. C est un système à flux tiré. (T. Ohno, 1959) Dans la suite de cet état de l art sur la planification de la production, nous nous intéresserons uniquement aux méthodes MRP afin de rester dans le cadre du sujet du projet. 13

19 3.1. PRÉSENTATION DES SYSTÈMES MRP 3.1 Présentation des systèmes MRP Historique Les premiers systèmes MRP datent des années 60. Au départ très simples, ils ont continué à évoluer jusqu à atteindre un haut niveau de fonctionnalités et d intégration dans le système d information de l entreprise. Aujourd hui, on classe les MRP en trois catégories selon leur niveau de fonctionnalités ([LD98]) : MRP0 (1960) : Système qui, à partir des demandes fermes et estimées de produits finis et des niveaux de stock courants, calcule les besoins en composants (quoi, combien et quand) permettant de répondre à la demande. Les capacités de production ne sont pas prises en compte. MRP1 (1970) : MRP0 auquel on a rajouté le calcul des charges engendrées sur l outil de production par le résultat du MRP. La planification s effectue toujours à capacité infinie. MRP2 (1979) : Évolution du MRP1 qui intègre le calcul des coûts de production et un algorithme d ajustement charge-capacité. Ce dernier permet d ajuster la charge souhaitée à la charge disponible pour chaque centre de production. La signification de l acronyme MRP a aussi changé au cours du temps. Initialement désignant Material Requirement Planning, il est dévenu Manufacturing Resource Planning pour souligner le fait que les dernières générations de MRP ne s appliquent plus uniquement à la planification des besoins en composant mais aussi à la planification des besoins en ressources Pré-requis pour la mise en oeuvre d un MRP Une des caractéristiques principales d un MRP par rapport à une autre méthode de planification de la production, est la masse de données requises pour établir les besoins en composants. C est pourquoi, le MRP est presque toujours intégré à une GPAO (Gestion de production assistée par Ordinateur) ou à un ERP. Conditions requises pour la mise en oeuvre d un MRP 0 : Existance d un plan directeur de production : il détermine, pour un horizon de planification donné, la demande prévisionnelle de chaque produit fini. Existance d une nomenclature complète des composants utilisés : elle permet d obtenir pour chaque produit, ses composants ainsi que les quantités nécessaires à son assemblage. Existance d un système d information fiable sur l état des stocks : le MRP nécessite une connaissance correcte de l état du stock d un composant (stock disponible, livraisons attendues,...) au début ou à la fin de chaque période de l horizon de planification. Existance d un fichier des délais d obtention : il est essentiel pour être capable de calculer les dates de lancement d un OF ou de passation d une commande. Conditions requises pour la mise en oeuvre d un MRP 1 : Existance d un fichier des gammes : les gammes déterminent les ressources utilisées par les opérations permettant ainsi de calculer les charges. Existance d un fichier des ressources : ce fichier permet d établir les capacités de production. 14

20 3.1. PRÉSENTATION DES SYSTÈMES MRP Conditions requises pour la mise en oeuvre d un MRP 2 : Existance d un fichier des coûts de production et de stockage Existance de fichiers nécessaires à la détermination des priorités : il permet de choisir les OFs à déplacer en priorité en cas de surcharge d une ressource La logique du MRP Le MRP est un processus itératif qui calcule pour chaque période de l horizon de planification et pour chaque produit, ses besoins en composants. Les produits sont traités par niveau de nomenclature croissant pour que le calcul des besoins s effectue en cascade. Ainsi, les besoins en composants générés pour un produit seront traités par la prochaine itération du MRP. Les besoins générés apparaissent toujours avec une certaine avance correspondant au délai de fabrication ou de livraison du composant. Fig. 3.1 Exemple de nomenclature à 4 niveaux de profondeur Produit Délai Lustre 2 Besoin Lancement Corps 1 Besoin Lancement Système d éclairage 2 Besoin Lancement Support 1 Besoin Lancement Ampoule 2 Besoin Lancement Commuateur 2 Besoin Lancement Plastique 1 Besoin Lancement Exemple Exemple de calcul des besoins en composants d un lustre Dans cet exemple, pour livrer 13 lustres en périodes 10, il faut les lancer en production 2 semaines plutôt ce qui génère des besoins en systèmes d éclairage et en corps de lustre pour la période 8. 15

21 3.2. DÉFAUTS DES SYSTÈMES MRP Généralement, le calcul de la quantité à mettre en production est toujours supérieure à la demande car il doit prendre en compte la taille des lots, les taux de rebus, le réapprovisionnement du stock de sécurité, etc. Ce calcul s effectue en deux temps : calcul des besoins bruts à partir de la demande calcul des besoins nets à partir des besoins brutes et des paramètres précédents 3.2 Défauts des systèmes MRP Le principal défaut de cette méthode de planification qu est le MRP, est la non prise en compte des capacités de production pour établir les ordres de fabrication. Ainsi, rien n assure que, pour une période donnée, tous les OF planifiés pourront être traités par l atelier de production. Le MRP suppose implicitement que le plan directeur de production a été dimensionné correctement par rapport aux capacités de production. Cependant, un PDP peut avoir été exagéré, ou à l inverse, les besoins en ressources n ont pas été anticipés. Dans ce cas, les conséquences sont multiples : Retards de livraison Pénalités financières Augmentation des files d attentes à cause des ressources goulets surchargées Augmentation des niveaux de stock 16

22 Chapitre 4 Planification des capacités de production Dans le chapitre précédent, nous avons vu que le principal défaut de l algorithme de base du MRP est la non considération des capacités de production lors de la planification des ordres de fabrication. Néanmoins, la gestion des capacités doit absolument être prise en compte pour éviter d obtenir des plans de production irréalisables. C est donc le rôle de la planification des capacités de production, qui interviendra à différents moments durant la phase d élaboration du plan directeur de production afin d éviter ces problèmes. Un problème souvent rencontré au sein des systèmes MRP est l existance d un PDP exagéré. Dans ce cas, le plan de production prévoit plus d ordres de fabrication que l atelier ne peut supporter. De plus, ce type de plan occasionne une augmentation des stocks de matières premières et de composants intermédiaires, une augmentation des files d attente au niveau des postes de travail, et du retard dans les livraisons. Ce chapitre présente donc les différentes techniques qui ont été développées pour s assurer que les plans de production sont réalisables. Fig. 4.1 Aperçu des différents techniques de gestion de capacité 17

23 4.1. PLANIFICATION DES BESOINS EN MOYENS DE PRODUCTION 4.1 Planification des besoins en moyens de production Principe La première phase de la gestion des capacités de production consiste à planifier les besoins en moyens de production à long terme (Resource Requirement Planning). Ce processus est similaire à celui du MRP, excepté qu au lieu de planifier les besoins en composants, on planifie les besoins en ressources humaines, matérielles et financières nécessaires à la réalisation du plan de production (PDP). En revanche, à la différence du MRP, cette planification porte sur l ensemble des périodes du PDP et utilise des familles d articles sans notion de niveaux de nomenclature (Planification hiérarchisée) Mise en oeuvre Dans un premier temps, il faut établir, pour chaque famille d articles, son profil de ressource qui définit les besoins en ressources nécessaires à la production d une unité de produit de la famille. Le temps de production d un article comprend les temps de production de tous ces composants. De plus afin de réduire le nombre de données à traiter, les ressources sont elles aussi regroupées par centre de charge. Famille Usinage Assemblage Peinture Emballage A 216,77 197,28 180, B 68,40 53,28 44,40 23,52 C 40,96 38,56 38,56 17,28 Tab. 4.1 Exemple de profils de ressources pour 3 familles d articles Dans cet exemple, l usinage d une unité de A demande 261,77 heures. Une fois que le profil de ressource a été établi pour chaque famille d articles, il ne reste plus qu à multiplier, pour chaque période du PDP, les temps obtenus grâce au profil par les quantités de production prévisionnelles. On obtient ainsi les capacités de production requises par le PDP à long terme. Généralement, on compare ces résultats avec les capacités disponibles afin de détecter les ajustements à réaliser. Ces ajustements peuvent nécessiter des investissements lourds dans de nouvelles unités de production qu il faut prendre en compte le plus tôt possible. 18

24 4.2. VALIDATION DU PLAN DIRECTEUR DE PRODUCTION 4.2 Validation du plan directeur de production Alors que la méthode précédente permet d établir les besoins en ressources nécessaires à la réalisation d un plan de production, celle-ci va permettre de valider l adéquation entre capacité disponible et charge du PDP, avant de lancer l exécution du MRP. La principale différence entre ces deux méthodes se situe au niveau de détails pris en compte. En effet, cette méthode n utilisant pas de planification hiérarchisée, elle calcule la charge engendrée par tous les produits. Actuellement, il existe trois techniques de validation de PDP que l on regroupe sous le terme RCCP (Rough Cut Capacity Planning). Ces techniques diffèrent en fonction des données requises et de leur compléxité Approche par facteurs globaux Cette technique, également appelée CPOF (Capacity Planning Using Overall Factors), est la plus ancienne. Elle s appuie sur les informations suivantes pour établir un planning prévisionnel des charges : un plan directeur de production le temps total nécessaire à la production de chaque partie d un produit la proportion de temps utilisé par chaque centre de charge de l atelier Pour présenter cette approche, nous allons nous baser sur un exemple. Imaginons un plan de production qui prévoit la production de lustres (cf. Figure 3.1) par mois et dont la durée de production moyenne d un lustre est de 0,22 heure. La première étape consiste à calculer le nombre d heures d atelier requises par mois en multipliant les quantités du PDP par le temps moyen de production d un produit. On obtient ainsi la dernière ligne du tableau ci-dessous. Ensuite, il suffit de diviser ce temps par la proportion historique de temps utilisé par chaque centre de charge pour obtenir sa charge prévisionnelle. La validation du PDP consiste alors à vérifier pour chaque période et chaque centre de charge que les capacités disponibles sont suffisantes. Centre de charge Proportion historique Jan Fev... Déc Moulage 0, Usinage 0, Assemblage 0, Peinture 0, Capacité requise Tab. 4.2 Planification des capacités par l approche des facteurs globaux Cette méthode est particulièrement bien adaptée aux ateliers fabriquant des produits d une même famille car dans ce cas il est facile d obtenir les proportions de temps de chaque centre de charge par rapport à l atelier. 19

25 4.2. VALIDATION DU PLAN DIRECTEUR DE PRODUCTION Approche par feuille de capacité Cette approche correspond à l approche par profil de ressource présentée dans la partie précédente. La seule différence est, qu à ce niveau, on ne traite plus les produits par famille et par type mais par référence. Par ailleurs, son rôle est axé sur la validation du PDP et non pas sur les investissements à réaliser Approche par profil de ressource Bien que le nom de cette approche ressemble à celle de la partie précédente, la méthode utilisée dans celle-ci est beaucoup plus précise et détaillée. Elle se base sur un plan de production et sur des profils de ressource établis pour chaque produit. Ces profils prennent en compte les durées opératoires de passage sur chaque ressource. Un profil se présente sous la forme d un tableau à 2 dimensions où les colonnes représentent les périodes de production à partir de la date de mise à disposition de l article, et les lignes les ressources nécessaires (cf. Tableau 4.3 et Tableau 4.4). L intersection d une ligne et d une colonne indique le temps de la ressource nécessaire à la fabrication d une unité de produits si elle doit être disponible à la date t. t - 2 t - 1 t R1 a 112 a 111 a 110 R2 a 122 a 121 a 120 Tab. 4.3 Profil de ressource du produit P1 sur les ressources R1 et R2 t - 2 t - 1 t R1 a 212 a 211 a 210 R2 a 222 a 221 a 220 Tab. 4.4 Profil de ressource du produit P2 sur les ressources R1 et R2 Produit / Période P1 b 11 b 12 b 13 P2 b 21 b 22 b 23 Tab. 4.5 Plan de production des produits P1 et P2 sur 3 mois Dans cet exemple, les produits P1 et P2 ont des durées de fabrication moyennes qui s étalent sur trois périodes. 20

26 4.2. VALIDATION DU PLAN DIRECTEUR DE PRODUCTION À partir du plan de production et des deux profils de ressource précédents, il est alors possible d établir la charge prévisionnelle de chaque ressource. Resource / Période R1 c 11 c 12 c 13 R2 c 21 c 22 c 23 Tab. 4.6 Charge prévisionnelle des ressources R1 et R2 sur 3 mois c 11 = a 110 b 11 + a 111 b 12 + a 112 b 13 + a 210 b 21 + a 211 b 22 + a 212 b 23 c 21 = a 120 b 11 + a 121 b 12 + a 122 b 13 + a 220 b 21 + a 221 b 22 + a 222 b 23 c 12 = a 110 b 12 + a 111 b 13 + a 210 b 22 + a 211 b 23 c 22 = a 120 b 12 + a 121 b 13 + a 220 b 22 + a 221 b 23 c 13 = a 110 b 13 + a 210 b 23 c 23 = a 120 b 13 + a 220 b 23 Le principal intérêt de cette méthode est la prise en compte des durées de production. La méthode est ainsi plus précise, au prix d un temps de calcul plus important. 21

27 4.3. PLANIFICATION DES BESOINS EN CAPACITÉ DE PRODUCTION 4.3 Planification des besoins en capacité de production La planification des besoins en capacité de production, aussi apppelée CRP (Capacity Requirement Planning) est apparue dans les années 70 avec les systèmes MRP1. Son rôle est de déterminer les capacités nécessaires pour exécuter une opération de production. En effet, à partir des ordres de fabrication fermes et planifiés, le CRP est capable de calculer la charge occasionnée par ces ordres sur les ressources d un atelier en simulant leur exécution. On obtient ainsi pour chaque période de temps de l horizon de planification, la charge et la capacité de chaque ressource. Généralement, le CRP est utilisé conjointement avec le MRP car il permet de vérifier que tous les ordres de fabrication prévus pourront réellement être traités par la production sans occasionner de dépassement de capacité. Ainsi, il est souvent le dernier test avant de valider un plan de production. Fig. 4.2 Boucle de contrôle PDP-MRP-CRP Par rapport aux méthodes décrites précédemment, les résultats du CRP sont beaucoup plus détaillés puisque cette méthode n effectue aucun regroupement de ressources Calcul de la charge Le CRP utilise les ordres de fabrication générés par le MRP et les décompose en fonction des centres de charge qu ils doivent traverser. Pour chacun des sous-ordres obtenus, il calcule la charge engendrée sur le poste de travail et l ajoute à la charge accumulée depuis le début de la période. Il fait de même avec les OF fermes et/ou planifiés manuellement afin d obtenir des informations de charge les plus justes possibles. La décomposition d un ordre de fabrication sur les postes de travail s obtient à partir de la gamme du produit à fabriquer. C est pourquoi, l existance d un fichier des gammes est devenue obligatoire à partir des systèmes MRP1. 22

28 4.3. PLANIFICATION DES BESOINS EN CAPACITÉ DE PRODUCTION Résultats du CRP Le CRP produit des diagrammes de charge par poste de travail. Ces diagrammes présentent pour chaque période la capacité disponible en nombre d heures et la charge engendrée par la planificiation. Ces diagrammes permettent d identifier les surcharges lorsque la charge engendrée dépasse la capacité disponible et les sous-utilisations dans le cas inverse. Fig. 4.3 Exemple de diagramme de charge généré par le CRP Dans les CRP récents, il est même possible de distinguer la charge ferme et la charge planifiée. 23

29 Chapitre 5 Techniques de lissage de charge Jusqu à présent, les techniques de planification des capacités de production étudiées ne servaient qu à vérifier l adéquation entre les charges prévisionnelles et les capacités disponibles des ressources. En cas de surcharge, il fallait reprendre le plan directeur de production et l adapter jusqu à ce que les problèmes disparaissent. Cependant, une surchage n est pas toujours synonyme de remise à plat du PDP, il existe des méthodes permettant de faire disparaître des surcharges temporaires. Généralement, on ne retrouve ces méthodes que dans les systèmes MRP-II sous l appelation ajustement charge-capacité. Les techniques de lissage de charge se classent en deux catégories en fonction l objet sur lequel elles agissent. Ainsi, le lissage en parallèle s applique sur les ressources alors que le lissage en série porte sur les opérations qui utilisent les ressources surchargées. 5.1 Lissage en parallèle Le lissage en parallèle est la solution la plus rapide à mettre en oeuvre face à un dépassement de capacité temporaire car elle consiste à augmenter la capacité des ressources surchargées au prix d un coût de production plus élevé. Lissage par ajustement des capacités : Le lissage par ajustement de capacité consiste à augmenter directement la capacité des ressources surchargées en augmentant leur disponibilité dans la mesure du possible. Dans ce cas, le responsable de la production peut soit augmenter le temps de travail en mettant en place des heures supplémentaires soit augmenter les cadences avec les risques que ça entraînent. Lissage par transfert de capacité : Aussi appelé lissage en parallèle, il consiste à faire appel à de la sous-traitance pour faire diminuer les charges de production ou à transférer la ou les opérations qui surchargent un poste sur des postes équivalents. 24

30 5.2. LISSAGE EN SÉRIE 5.2 Lissage en série Si tous les postes d une même famille de postes interchangeables sont surchargés sur une période donnée, cela signifie que seul le lissage «en série» (décalage dans le temps de l opération) pourra annuler la surcharge. Il existe alors deux possibilités : le décalage à droite et le décalage à gauche. Le décalage à droite ne peut être envisagé que de manière exceptionnelle, en jouant sur le stock de sécurité ([LD98]). La complexité du problème tient au fait que toute modification sur un composant nécessite le recalcul sur les composants enfants. Il faut donc rappeler le MRP sur le produit concerné et tous ses composants après tout décalage à gauche. De plus, le report de production implique la constitution de stock qui a un coût. Lorsqu une ressource est surchargée par plusieurs opérations planifiées et que seul le lissage en série peut être appliqué, il faut choisir l opération à décaler. Dans ce cas, [VG88] préconise l existance d un fichier définissant des règles de priorité pour déterminer l opération à décaler. Ces règles sont généralement calculées sur la base de critères empiriques tels que celui de la minimisation de la valeur des en-cours constitués lors de décalage. Généralement, on choisit l opération dont le coût de déplacement est le plus faible. 5.3 Limitations Dans le cas du lissage en série, le lissage s effectue toujours de la période de temps la plus éloignée vers la plus proche. Cette démarche se justifie par le lissage de la charge par un transfert des dépassements sur les périodes antérieures. Si après lissage, la solution du MRP n est toujours pas réalisable, le plan directeur de production doit être révisé. Cette remise en cause se traduit par un retard de livraison de certains articles par rapport à ce qui était initialement prévu. Il faut alors mettre en place des procédures de traçage (pegging) pour déterminer les commandes à l origine des surcharges. 25

31 Chapitre 6 Conclusion de l état de l art Cet état de l art nous a permis de comprendre le fonctionnement d un MRP et de soulever son principal défaut, à savoir la non prise en compte des capacités de production lors de l élaboration de la planification. Néanmoins, il existe un certain nombre de méthodes permettant de planifier les besoins en capacités de production à différents moments dans le système de gestion de production. Toutefois, peu de solutions existent au niveau du MRP car la masse de données est généralement trop importante pour être traitée à ce niveau. C est pourquoi, la plupart des méthodes agissent sur les données pré-mrp telles que le plan directeur de production pour vérifier l adéquation entre PDP et capacité de production. Ainsi, la méthode RRP permet d anticiper les besoins en ressources, et les RCCP permettent de valider le plan directeur. Cependant, ces méthodes ne peuvent assurer à 100% qu il n y aura pas de dépassements de capacité. Il existe donc des techniques de lissage de charge qui peuvent être appliquées sur les résultats du MRP pour tenter de faire disparaître les problèmes de dépassements de capacité temporaires. Ce type de procédé n est apparu qu avec les MRP de type 2. De nombreux progiciels du marché se réclamant être de type MRP2, ne sont en fait que des MRP1 auxquels on a ajouté un CRP. Cet élément est obligatoire pour détecter les surcharges engendrées par la planification du MRP. C est alors au décideur de mettre en place les actions nécessaires pour résoudre les problèmes de charge. 26

32 Troisième partie Analyse de l existant 27

33 Chapitre 7 Étude du MRP existant Le MRP existant dans Ofbiz a été développé par Thierry Grauss en 2004 dans le cadre de son projet de fin d étude [TG04]. Le but de ce projet était de mettre au point l algorithme utilisé par le MRP pour calculer les besoins en composants à partir de commandes de vente d articles. Cependant, il a été réalisé avant la naissance de projet Néogia, il n est donc pas intégré à OfbizNéogia. De plus, les structures de données ont fortement changé, il sera donc nécessaire de le porter sur la nouvelle architecture. Une telle opération requiert un bon niveau de connaissance des deux projets d où l objet de cette partie. 7.1 Données manipulées par le MRP Ofbiz n intègre pas de plan directeur de production. Pour pallier ce manque, le MRP de Thierry utilise les enregistrements de la table des commandes de vente comme données d entrées du MRP. Ces enregistrements sont ensuite utilisés pour initialiser la table de travail du MRP, à savoir la table mouvements de stock planifiés. Cette table permet de suivre l évolution des besoins et des arrivées de stock suite à la simulation de lancement d ordres de fabrication (OF) ou d ordres d achat (OA) par le MRP. Ces simulations sont conservées dans la table des propositions. Fig. 7.1 Données d entrée/sortie du MRP existant 28

34 7.2. FONCTIONNALITÉS 7.2 Fonctionnalités En terme de fonctionnalités, le MRP existant se situe entre le MRP0 et le MRP1 car bien qu il ne prenne pas en compte les capacités de production, il utilise la disponibilité des ressources pour déterminer les délais de d obtention des composants. Le MRP réalisé est du type multi-articles multi-niveaux, c est-à-dire qu il traite tous les articles de la table des mouvements planifiés de stocks par niveau de nomenclature, en commençant par le niveau 0. Pour chaque niveau, il applique alors l algorithme de calcul des besoins présenté dans l état de l art sur chaque article, et passe au niveau suivant. Cet algorithme émet des propositions d ordre de fabrication ou d achat lorsque le niveau de stock d un article passe en-dessous de son seuil de sécurité. Par rapport aux MRP du marché à niveau de fonctionnalités équivalent, il lui manque tout de même une fonction : une notion d horizon de planification afin de limiter la planification des besoins en composants à une période de temps de durée raisonnable. Ce point devra être pris en considération lors du portage du MRP sur la nouvelle architecture d OfbizNeogia. 7.3 Particularités Contrairement à ce qu on trouve dans la littérature ([GP75], [VG88], [LD98]), ce MRP ne fonctionne pas sur une base périodique mais en temps continu : il prend les mouvements de stock planifiés les uns à la suite des autres sans les regrouper par période. Cette absence de découpage temporel de l horizon de planification s explique par deux raisons. D une part, ni Ofbiz ni OfbizNéogia n implémentent la gestion d un plan directeur de production, qui lui est périodique. D autre part, il est difficile de trouver une taille de période homogène avec les durées de fabrication des différents produits. Une des conditions nécessaires à la réalisation d un MRP est de disposer d un fichier de la durée de fabrication moyenne de chaque article ([VG88]). Or dans le MRP existant, cette durée est calculée à partir de la date de fabrication, de la gamme opératoire et de la disponibilité des ressources. Cette approche est plus coûteuse en temps de calcul car il faut recalculer la durée de fabrication à chaque fois. En revanche, elle est beaucoup plus précise puisqu elle prend en compte les périodes de disponibilité des ressources ce qui permet d utiliser le MRP pour de la planification à court terme. 29

35 Chapitre 8 Module de gestion de production Le module de gestion de production a été le premier module développé par Néréide pour Ofbiz. Ce module a été ensuite porté sur l architecture Néogia par Thierry Grauss durant le stage qui a suivi son PFE. Il comporte actuellement quatres sous-modules : gestion des données techniques ; gestion d atelier ; gestion de projet ; gestion des coûts de production ; Dans ce chapitre, seuls les deux premiers sous-modules seront détaillés car leurs entités et leurs fonctionnalités seront utilisées par le MRP et le CRP. 8.1 Gestion des données techniques Le module de gestion des données techniques est utilisé principalement par le bureau des méthodes pour définir tous les processus de fabrication (outils, phases d exécution, gammes, etc) intervenant dans la production d un article. Ces données sont ensuite utilisées par le module de gestion d atelier pour planifier des ordres de fabrication Les ressources Les ressources d un atelier sont représentées par l entité TechDataResource. Une ressource peut être soit une machine soit une compétence, par exemple : un tour, un régleur. Il est possible de regrouper plusieurs ressources physiques sous une seule TechDataResource si ces ressources sont identiques et qu elles peuvent être interchangées à tout moment. Dans ce cas, l attribut resourcequantity indique le nombre de ressources de ce type Le calendrier industriel L entité TechDataCalendar représente un calendrier industriel. Un calendrier industriel définit les périodes de disponibilités et/ou d indisponibilités d une ressource. Il est utilisé notamment pour définir les périodes de maintenance et les périodes de fermeture de l atelier. Les ressources 30

36 8.1. GESTION DES DONNÉES TECHNIQUES Fig. 8.1 Modélisation d une ressource d atelier d un atelier ne partagent pas forcément toute le même calendrier industriel. La mise en oeuvre d un calendrier industriel se fait de la manière suivante : L utilisateur définit une période hebdomadaire typique (CalendarWeek) pour laquelle il indique pour chaque jours l heure de début de disponibilité ainsi que la durée. Ensuite, il introduit des exceptions (CalendarException) dans le calendrier. Une exception est définit par une date, une nouvelle heure de début de disponibilité et une nouvelle durée. Fig. 8.2 Modélisation UML du calendrier industriel L implémentation existante du calendrier industriel ne propose qu une seule méthode add qui calcule la date de fin d utilisation d une ressource à partir de sa durée et de sa date de début, et inversement. Le CRP nécessitera des méthodes plus complexes pour pouvoir étudier les disponibilités des ressources sur un horizon de planification Les gammes opératoires Une gamme opératoire définit l ensemble des opérations nécessaires à la réalisation ou l assemblage d un produit. Elle est représentée dans OfbizNéogia par l entité Routing. Une gamme est toujours associée à un unique produit par contre un produit peut avoir plusieurs gammes, exemple : une gamme standard et une gamme faisant intervenir de la sous-traitance. L attribut 31

37 8.1. GESTION DES DONNÉES TECHNIQUES scrapfactor définit le taux de rebus généralement constaté lors de l exécution de la gamme, c està-dire le nombre de pièces non conformes par rapport au nombre de pièces produites. Enfin, la gamme définit l ordre de ses opérations via l attribut SequenceNum de la classe d association RoutingComposition. Fig. 8.3 Modélisation UML des gammes et des opérations Les opérations Les opérations d une gamme sont modélisées par l entité Task. Une opération est définie par sa durée opératoire (estimatedleadtime), son temps de préparation (estimatedsetuptime), et par les ressources nécessaires à sa réalisation (TaskResource). Parmi ces ressources, il y en a obligatoirement une dont l attribut valueforplanification est défini à vrai. Cette ressource est alors utilisée en priorité pour effectuer la planification de l exécution de l opération Les nomenclatures Les nomenclatures ne sont pas modélisées dans le module de gestion des données techniques d OfbizNéogia car Ofbiz possédait déjà un support complet des nomenclatures dans le module Product. Avec notamment, la possibilité de gérer des variantes d un même produit via un objet appelé Configurator dans le cas de produits avec options. Ofbiz modélise les arcs d une nomenclature comme une association entre deux produits composé-composant (entité ProductAssoc). Chaque arc porte le nombre de composants (quantity), la tâche de la gamme qui requiert le(s) composant(s) (routingworkeffortid) et une période de validité. 32

38 8.2. GESTION D ATELIER 8.2 Gestion d atelier Le module de gestion d atelier se charge de la programmation des ordres de fabrication et de leur suivi. En relation avec le module de gestion des stocks, il s occupe aussi de la réservation des composants et des demandes de sorties de stocks Les ordres de fabrication Un ordre de fabrication, représenté par l entité WRun, est une programmation de l exécution d une gamme. Un OF est défini par l article à produire et sa quantité, par son statut (Planifié, Ferme, EnCours,...), par ses dates de réalisations et durées estimées / réelles, ses besoins en composants et enfin par les opérations qui le composent (TaskFulfilment). Ces opérations correspondent aux opérations déclarées au niveau de la gamme. L entité TaskFulfilment représente la programmation d une opération. Comme pour un ordre de fabrication, on retrouve des informations sur les dates de début et de fin estimées/actuelles, et un statut qui indique l état de réalisation de l opération. Un TaskResourceFulfil représente l utilisation réelle et/ou planifiée d une resource pour la réalisation d une opération. Un RunComponent représente un besoin d un composant particulier. Il doit toujours être disponible au début de l opération à laquelle il est lié (TaskFulfilement). Fig. 8.4 Modélisation UML des ordres de fabrication 33

39 8.2. GESTION D ATELIER Programmation de la production La création d un OF entraîne la programmation de toutes les opérations qui le composent, la déclaration des mouvements de stocks associés aux sorties de stocks des composants et à la production du produit associé à l OF. Ces mouvements de stocks deviendront fermes une fois l OF validés. Dans sa version initiale, la planification d un OF se fait au plus tôt à partir de sa date de début estimée (forward scheduling). Ce comportement est incompatible avec le fonctionnement du MRP qui effectue sa planification à partir des dates de fin. Il faudra donc prendre en compte ce point lors de l élaboration du MRP et de ses algorithmes de planification. Enfin, il n est pas possible d effectuer une replanification partielle ou totale d un OF. 34

40 Quatrième partie Développements réalisés 35

41 Chapitre 9 Solution mise en oeuvre L objet de cette partie est de présenter la solution mise en oeuvre pour réaliser un MRP à capacité finie, intégré au module de gestion de production de l ERP libre OfbizNéogia. Cette solution se base sur les observations réalisées dans l état de l art sur la gestion des capacités de production, et sur l étude des fonctionnalités existantes du module de gestion de production. En outre, la mise en oeuvre d un tel système étant complexe, une approche descendante a été privilégiée pour réaliser l analyse du système. Ainsi, nous verrons dans un premier temps en quoi consiste un MRP à capacité finie et un algorithme de lissage de charge. Ces premiers éléments permettront ensuite d élaborer les spécifications fonctionnelles du système et les différents modules à développer. 9.1 Présentation de la solution Principe Après avoir étudié les différentes méthodes concernant la planification des capacité de production et le lissage des charges, il apparaît qu un MRP à capacité finie est simplement un MRP traditionnel auquel on associe un CRP et un algorithme de lissage de charge. Dans cette approche, le MRP génère des propositions de fabrication que le CRP évalue pour déterminer les ressources qui sont surchargées et celles qui ne le sont pas. On fait ensuite appel à un algorithme de lissage pour essayer d étaler les dépassements de charge. Si après lissage, les problèmes de surcharge perdurent, cela signifie que soit les capacités de production sont insuffisantes, soit le plan directeur de production est exagéré. Voici quelques éléments à prendre en compte pour l élaboration du MRP à capacité finie : Découpage temporel : contrairement au MRP existant dans Ofbiz, l analyse de la charge des ressources doit s effectuer par période car la masse de données à ce niveau est trop importante pour pouvoir traiter ce problème en temps continu. Donc le CRP et l algorithme de lissage doivent travailler sur une base de temps périodique. Lissage à postériori : le lissage de la charge engendrée ne peut s effectuer qu après une première itération du MRP à capacité infinie. En effet, le lissage n est efficace que s il est réalisé sur une solution compléte (prenant en compte toutes les charges). Méthode itérative arrière : l algorithme de lissage peut être amené à avancer une opération pour étaler la charge. Cette action peut modifier les besoins en composant et donc générer 36

42 9.1. PRÉSENTATION DE LA SOLUTION de nouveaux ordres de fabrication qui perturberont les charges sur les périodes précédentes. C est pourquoi le lissage doit toujours s effectuer de la période la plus éloignée vers la plus proche Place du décideur Dans un système MRP sans mécanisme de lissage, on remet en cause le plan directeur de production lorsque les propositions du MRP ne sont pas réalisables. En effet, le PDP est supposé avoir été établi en prenant en compte les capacités de production. Dans ce cas, le décideur doit intervenir pour déterminer les causes de la surcharge, ajuster le PDP en conséquence et relancer la planification (cf. Figure 9.1). Fig. 9.1 Processus de décision dans un MRP sans lissage Cependant, il peut aussi décider d introduire manuellement des ajustements et/ou des transferts de capacité pour faire disparaître les surcharges. Seulement, ce type d opération n est pas aisé à réaliser à cause notamment de la masse de données. C est donc à ce moment que l algorithme de lissage va intervenir pour automatiser certains ajustements. Pour cela, on introduit un nouveau scénario qui intégre une phase de lissage des charges. Il sera utilisé en premier lieu pour essayer de résoudre les problèmes de dépassement de capacité. En cas d échec, il sera possible de revenir au scénario précédent. Fig. 9.2 Processus de décision dans un MRP avec lissage Les techniques de lissage de charge présentées dans l état de l art reposent principalement sur l augmentation des capacités de production avec la mise en place d heures supplémentaires, sur le transfert de capacité avec de la sous-traitance, et sur l avancement de certaines opérations. Les deux premiers points pouvant avoir des conséquences qui dépassent strictement le cadre 37

43 9.2. ALGORITHME DE LISSAGE EN SÉRIE SIMPLIFIÉ économique, nous laisserons au décideur le choix d avoir recours à ces méthodes. En revanche, l avancement des opérations qui provoquent les surchages peut facilement être automatisé par un algorithme de lissage en série. Le seul risque économique concerne l augmentation du coût des stocks en raison de la hausse des en-cours. Ainsi dans ce nouveau scénario, lorsque les propositions du MRP ne sont pas réalisables, on fait appel au décideur qui peut au choix augmenter les capacités des ressources surchargées, transférer certaines charges vers de la sous-traitance ou bien ne rien faire. On fait appel ensuite à l algorithme de lissage pour tenter de résoudre les problèmes de dépassements de capacité restants et pour mettre à jour la planification. 9.2 Algorithme de lissage en série simplifié L algorithme de lissage présenté ci-dessous a été élaboré à partir d une description du principe d ajustement charge-capacité décrit par Vincent Giard ([VG88]). Il consiste à étudier toutes les périodes de l horizon de planification en partant de la dernière période et à reporter les dépassements de capacité sur les périodes précédentes. Si un dépassement de capacité est causé par plusieurs opérations, le choix de l opération à avancer s effectue à l aide d une fonction de décision paramétrable par l utilisateur. Idéalement, cette fonction devrait choisir l opération qui minimise le coût du décalage. Le décalage d une opération consiste à replanifier partiellement l OF à partir de l opération concernée en prenant en compte cette fois les contraintes de capacité existantes. Toutefois, la replanification peut échouer si aucune programmation respectant les capacités n est trouvée. Dans ce cas, l opération tombe dans la période de rejet (période 0) qui indique que la solution après lissage n est toujours pas réalisable. Après la replanification d une opération, il est nécessaire de relancer le MRP uniquement sur l article traité par l OF et ses composants pour mettre à jour les besoins en composants. Cette mise à jour peut générer de nouveaux ordres de fabrication et donc entraîner de nouveaux dépassements de capacité. 38

44 9.3. ANALYSE DES BESOINS FONCTIONNELS 9.3 Analyse des besoins fonctionnels L élaboration de l algorithme de lissage était une étape obligatoire pour établir les besoins fonctionnels car il détermine les fonctionnalités que le MRP et le CRP doivent implémenter. Ainsi, il doit être capable de récupérer des informations sur les ressources surchargées, de faire appel à des méthodes de replanification prenant en compte les contraintes de capacité et de relancer le MRP sur un article donné. À partir de ces quelques besoins de haut niveau, une analyse descendante a permis d obtenir la décomposition fonctionnelle résumée par le diagramme ci-dessous (Figure 9.3). Ce diagramme montre bien que l algorithme de lissage repose entièrement sur les fonctionnalités du MRP et du CRP, et que tous les développements vont porter sur ces deux modules. Fig. 9.3 Décomposition fonctionnelle du MRP à capacité finie MRP Le MRP existant dans Ofbiz, représenté par le bloc fonctionnel MRP multi-niveau, ne peut être repris tel quel dans OfbizNeogia. D une part, les entrées/sorties du MRP doivent maintenant utilisées les modules de gestion des stocks et de gestion de production d OfbizNeogia. D autre part, l intégration dans ces modules sera simplifiée si le MRP utilise les technologies de Néogia, à savoir la modélisation en UML et la génération de code. Par ailleurs, l algorithme de lissage nécessite une version modifiée du MRP pour effectuer la mise à jour des besoins en composant d un unique article. C est donc l occasion de repenser le MRP pour que les deux versions différentes partagent un maximum de code, et pour faciliter l ajout de nouveaux types de MRP tel que les MRP différentiels 1. Dans le diagramme, le code commun aux deux versions du MRP apparaît dans le bloc fonctionnel MRP mono-article mono-niveau. Comme son nom l indique, il ne calcule des propositions de réapprovisionnement uniquement pour un article donné sans descendre dans les niveaux de nomenclature. On peut ensuite implémenter les deux autres MRP à partir de celui-ci. 1 MRP qui prend en compte ses propositions précédentes pour effectuer une replanification partielle. 39

45 9.3. ANALYSE DES BESOINS FONCTIONNELS CRP Le rôle du CRP est de détecter les dépassements de capacité de chacune des ressources de l atelier. Pour atteindre cet objectif, le CRP doit conserver pour chacune des ressources, un planning d utilisation mis à jour à chaque fois qu un ordre de fabrication est programmé. Ce planning, initialisé à partir du calendrier industriel, doit permettre d obtenir rapidement (c-à-d sans calcul) la capacité et la charge ferme et/ou planifiée d une ressource pour une période de temps donnée. L exactitude du CRP repose essentiellement sur la cohérence du planning de chaque ressource. Pour obtenir une planification fiable et cohérente, il centralise donc toutes les méthodes de planification. Par conséquent, il faudra modifier les méthodes du module de gestion d atelier pour qu elles utilisent celles du CRP. Enfin, il doit fournir des éléments d interface graphique pour permettre au décideur de visualiser les ressources surchargées ainsi que leur diagramme de charge pour déterminer quelles sont les opérations qui provoquent les dépassement de capacités. Fig. 9.4 Exemples d interfaces graphiques possibles pour le CRP 40

46 Chapitre 10 Développement du MRP Le MRP existant ne peut être repris tel quel dans OfbizNéogia car d une part il n utilise pas les nouvelles structures de données introduites par Néogia, et d autre part il ne dispose pas des fonctionnalités nécessaires au CRP. En particulier, après avoir replanifier un ordre de fabrication, il faut être capable de refaire tourner le MRP sur l article concerné par l OF pour mettre à jour le planning de réapprovisionnement des tous ses composants. De plus, Néréide souhaite finaliser le MRP pour le proposer à ses clients. Il doit donc être parfaitement intégré à OfbizNéogia tant fonctionnellement que graphiquement. Le développement du MRP a consisté dans un premier temps à identifier les données en entrée et en sortie du MRP à partir de l implémentation existante, et à leur trouver un équivalent dans OfbizNeogia. Ensuite, l algorithme général du MRP a été rendu plus modulaire pour pouvoir être réutilisé dans des variantes du MRP. Enfin, la dernière étape a été d intégrer le MRP dans OfbizNéogia sous forme de services et d interfaces graphiques 10.1 Modélisation du MRP Les entrées Dans toute la littérature à propos des MRP, on indique que les données d entrée d un MRP proviennent du plan directeur de production qui contient pour chaque article ses prévisions de production pour l horizon de planification. Or dans OfbizNéogia, ce plan directeur de production n est pas encore implémenté, on doit donc utiliser une autre source de données : les mouvements planifiés de stock du module de gestion des stocks d OfbizNéogia, Facility. Un mouvement planifié de stock, représenté par l entité StockEventPlanned, est défini par un article sur lequel porte le mouvement, une quantité qui indique le sens du mouvement (positive indiquant une entrée de stock, négative une sortie) et une date de réalisation. Le mouvement deviendra effectif s il est transformé en mouvement réalisé avant cette date. Cette distinction entre mouvements planifiés et réalisés permet d introduire les notions d ATP (Available To Promise) et de QOH (Quantity On Hand). L ATP permet de calculer une estimation du niveau de stock d un article pour une date donnée à partir du stock réel (QOH) et des mouvements planifiés. Mais l avantage avec Néogia et ses outils de développement est qu il est possible de modéliser 41

47 10.1. MODÉLISATION DU MRP des spécialisations. Ainsi dans le cas des mouvements planifiés de stock, on peut distinguer les mouvements causés par la mise en production d un article (RunStockEventPlanned et Run- CompoStkEvPlan) de ceux provoqués par une commande clients (OrderStockEventPlanned). La quantité d un RunStockEventPlanned est toujours positive car il correspond à la production d un ou plusieurs articles résultant d un OF. Alors que celle d un RunCompoStkEvPlan est toujours négative car il correspond à un besoin en composants. Enfin, dans le cas d un OrderStockEventPlanned, le signe de la quantité dépend du type d ordre : positif pour un ordre d achat et négatif pour un ordre de vente. Fig Données d entrée du MRP 42

48 10.1. MODÉLISATION DU MRP Les sorties Lorsque le niveau de stock d un article, traité par le MRP, passe en-dessous de son seuil de sécurité, le MRP va créer un besoin caractérisé par une quantité requise et une date à laquelle le besoin doit être rempli. Ce besoin se traduit par une proposition (ProposedOrder) qui peut prendre soit la forme d un ordre d achat (OrderItem), pour les matières premières ou les produits sous-traités, soit la forme d un ordre de fabrication (WRun) pour les produits manufacturés. Fig Données de sortie du MRP Dans le cas d une proposition d ordre d achat, la création de la proposition entraîne la création d une commande d achat (OrderHeader) avec pour unique produit commandé (OrderItem), l article de la proposition. Enfin, La commande est créée avec comme date de livraison la date du besoin. À terme, la création de commandes d achat pourrait être confiée à un module achat qui effectuerait des regroupements pour les commandes ayant le même fournisseur et/ou les mêmes délais de livraison par exemple. Dans le cas d une proposition d ordre de fabrication, un nouvel OF est créé avec pour date de fin, la date du besoin, pour quantité, la quantité requise et pour la gamme, elle est choisit automatiquement à partir des données techniques. Cette quantité peut être modifiée en fonction de la taille des lots et du taux de rebus indiqués par la gamme utilisée par l OF. Ensuite, ce dernier est jalonné à partir de sa date de fin en utilisant une méthode de planification arrière. La création d un ordre d achat ou de fabrication entraîne la déclaration des mouvements de stocks planifiés engendrés par l exécution potentielle de ces ordres. Bien que ces derniers ne soient pas validés par le décideur, il est nécessaire de générer les mouvements de stocks pour que le MRP les prenne en compte lors de sa prochaine exécution ou lors du traitement du niveau de nomenclature suivant. 43

49 10.1. MODÉLISATION DU MRP Structures de contrôle du MRP Jusqu à présent les diagrammes UML présentés ne montraient que les données manipulées par le MRP mais pas son implémentation ni son interface de contrôle. Fig Structures de contrôle du MRP L élément principal du MRP est l entité MrpRun qui représente les paramètres d exécution du MRP ainsi que les propositions obtenues. Il définit notamment la configuration de l horizon de planification avec les attributs planningstartdate et planninglength. Il a aussi pour rôle de filtrer les mouvements de stocks selon la configuration du MRP. Afin de pouvoir facilement étendre les fonctionnalités du MRP, le design pattern Stratégie ([DG02]) a été employé pour modéliser les algorithmes du MRP. Ainsi, tout nouvel algorithme doit implémenter l interface Mrp qui définit les fonctionnalités minimales attendues et uniformise l utilisation des ces algorithmes. Le MRP est un processus long et consommateur de ressources, qui peut durer plusieurs heures. Il faut donc éviter de bloquer le serveur d application et tous ses utilisateurs quand le MRP s exécute. Pour cela, l algorithme du MRP est exécuté dans un thread différent de celui de l interface. En contre partie, il est nécessaire de mettre en place un mécanisme de synchronisation pour contrôler l exécution du MRP. C est le rôle de la classe MrpController qui implémente le design pattern Singleton ([DG03a]) pour n autoriser qu une seule instance de cette classe. Outre son rôle de contrôle de l exécution du MRP, cette classe assure aussi l interface avec les utilisateurs du MRP. Ainsi, à travers les méthodes de la classe MrpController, l utilisateur peut contrôler l exécution du MRP, récupérer et modifier son état, et lire les messages d erreur. Cette classe joue le rôle de façade ([DG03b]) qui cache la complexité du système sous-jacent. 44

50 10.1. MODÉLISATION DU MRP Fig Diagramme d état du MRP 45

51 10.2. ALGORITHMES MIS EN OEUVRE 10.2 Algorithmes mis en oeuvre Algorithme du MRP mono-article mono-niveau Pour la mise en oeuvre du CRP et de la méthode de lissage envisagée, deux algorithmes légèrement différents du MRP vont être nécessaires. Les principales différences entre ces algorithmes se situent au niveau des paramètres d entrée. En effet, dans une des versions du MRP, nous aurons besoin de traiter tous les articles du catalogue produit alors que dans l autre seulement ces composants. Cependant le principe du MRP reste le même pour ces deux algorithmes, il donc possible de partager leur partie commune. Les procédures AvailableToPromise et MinimumStockLevel sont des fonctions du module de gestion des stocks. La première renvoie une estimation du niveau de stock d un article donné pour une date donnée. Cette estimation est établie à partir du niveau de stock courant de l article et des mouvements planifiés de stock prévus jusqu à la date indiquée. La seconde récupère la taille du stock de sécurité de ce produit, c est-à-dire le niveau en-dessous duquel le niveau de stock ne devrait pas passer. La procédure SelectStockEventPlanned récupère tous les mouvements de stock planifiés durant l horizon de planification spécifié pour un article donné. Les mouvements sont renvoyés triés par date croissante, ainsi la cohérence du niveau de stock de l article est préservée pendant les itérations de l algorithme. 46

52 10.2. ALGORITHMES MIS EN OEUVRE Algorithme du MRP mono-article multi-niveaux Cet algorithme implémente un MRP qui traite uniquement un article et tous ses composants. Il sera utilisé par l algorithme de lissage de charge après avoir rejalonné un OF pour réajuster les besoins en composants et le niveau de stock de l article produit par l OF. Itération ProductSet 1 {Table} 2 {Plateau, Pied, Vis} 3 {Pied, Vis, Plaque} 4 {Vis, Plaque, Tasseau} 5 {Plaque, Tasseau} 6 {Tasseau} 7 {} Nomenclature utilisée pour l exemple Exemple Évolution du ProductSet du MRP mono-article multi-niveaux 47

53 10.2. ALGORITHMES MIS EN OEUVRE Algorithme du MRP multi-articles Cet algorithme correspond au MRP existant dans Ofbiz, c est-à-dire qu il génère des propositions d ordre de fabrication ou d achat pour maintenir les niveaux de stock à leur minimum pour tous les articles du catalogue produit sur l horizon de planification spécifié. Il a été adapté pour utiliser l algorithme du MRP mono-article mono-niveau afin de partager le maximum de code possible entre les différents algorithmes présentés. Au lieu de lancer le MRP sur tous les articles de l entreprise, cet algorithme se limite aux articles dont il existe un mouvement de stock dans l horizon de planification considéré. Cette petite optimisation évite ainsi d interroger la base de données pour les articles dont on est sûr qu ils ne vont pas être traités par le MRP. Cette limitation du nombre d articles traités est réalisée par la procédure SelectProductForMrp. L algorithme du MRP multi-articles doit se terminer lorsque tous les mouvements de stocks de l horizon de planification ont été traités. Or il n est pas possible d obtenir cette information simplement à cause de la masse de données générées. Donc, pour déterminer la fin de l algorithme, la donnée d entrée MaxBomLevelWithNoEvent a été introduite. Elle indique au bout de combien de niveaux de nomenclature successifs sans mouvement de stock généré on peut considérer le MRP comme terminé. La procédure SelectProductForMrp présente un défaut qu il faudra impérativement corriger avant d utiliser le MRP dans un système en production : elle ne vérifie pas, si le réapprovisionnement de l article doit se faire via un MRP ou via une méthode de gestion scientifique des stocks. Il existe bien un champ RequirementProductEnumId prévu à cet effet dans l entité Product mais pour l instant aucune valeur n existe pour cette énumération. 48

54 10.3. INTÉGRATION DANS OFBIZNÉOGIA 10.3 Intégration dans OfbizNéogia L intégration du MRP dans OfbizNeogia consiste : d une part, à déclarer les services du MRP pour qu ils puissent être appelés par tous les moyens mis à disposition par le ServiceEngine d Ofbiz, et d autre part à mettre au point les interfaces graphiques nécessaires pour que l utilisateur puisse se servir du MRP Services du MRP Pour que l utilisateur puisse contrôler le MRP depuis une interface graphique, il faut rendre les fonctionnalités de classe MrpController disponibles sous la forme de services. Un service permet d exécuter une procédure indépendamment de son langage de programmation, de sa localisation. Il est possible de passer et de récupérer des paramètres à un service, de ne le rendre exécutable que par un utilisateur authentifié, de l exécuter dans une transaction de base de données, etc. <-- MrpController developed services --> <service name="initmrp" engine="java" invoke="initmrp" location="org.ofbiz.manufacturing.planning.developed.mrpcontroller" auth="true"> <description>start Manufacturing Requirements Planning computation</description> <attribute name="mrprunidname" type="string" mode="in" optional="false"/> </service> <service name="resetmrp" engine="java" invoke="resetmrp" location="org.ofbiz.manufacturing.planning.developed.mrpcontroller" auth="true"> <description>reset the Manufacturing Requirements Planning process</description> </service> <service name="startmrp" engine="java" invoke="startmrp" location="org.ofbiz.manufacturing.planning.developed.mrpcontroller" auth="true"> <description>start Manufacturing Requirements Planning computation</description> </service> <service name="runmrp" engine="java" invoke="runmrp" use-transaction="false" location="org.ofbiz.manufacturing.planning.developed.mrpcontroller" auth="true"> <description>run Manufacturing Requirements Planning computation</description> </service> <service name="cancelmrp" engine="java" invoke="cancelmrp" location="org.ofbiz.manufacturing.planning.developed.mrpcontroller" auth="true"> <description>cancel Manufacturing Requirements Planning computation</description> </service> <!-- End of MrpController developed services --> Fig Extrait du fichier servicedef.xml du module gestion de production On remarque que pour le service runmrp, qui correspond à l exécution du MRP, l utilisation des transactions est désactivée. En effet, l utilisation d une transaction assure l isolation des 49

55 10.3. INTÉGRATION DANS OFBIZNÉOGIA requêtes vers la base de données, en contre-partie des mécanismes d accès exclusif à certaines tables peuvent empêcher des utilisateurs d accéder à ces tables. Or le MRP est un processus long et il faut éviter ce type de cas de figure. C est pourquoi, les transactions sont désactivées au niveau du service et gérées manuellement au niveau du code du MRP Interfaces graphiques du MRP Le MRP propose trois types d interfaces graphiques selon les fonctionnalités auxquelles l utilisateur souhaite accèder. La première est une interface principale qui permet de configurer le MRP, de l exécuter, puis de lister les ordres de fabrication ou d achat proposés. Pour l instant cette interface ne dispose pas d un mécanisme permettant de mettre à jour les résultats du MRP au fur et à mesure de son avancement. L utilisateur est alors obligé de recharger manuellement la page de son navigateur. Cette limitation est due au fait que le MRP et le serveur d applications tournent sur la même machine, et qu un rechargement automatique de la page peut être coûteux sur le serveur et peut ralentir le MRP (accès à la base de données, pages dynamiques,...). Fig Interface principale du MRP Contrairement à la première interface, la seconde est une page de gestion des MrpRun qui a été entièrement générée par les générateurs de code de Néogia à partir du diagramme de classes du MRP. Elle permet de lister les MrpRun, de les supprimer et d en créer de nouveaux. Fig Interface de gestion des MrpRun Le but de la dernière interface développée est de pallier les défauts de l interface principale, à savoir l impossibilité de suivre l avancement du MRP de manière automatique à cause de la charge engendrée sur le serveur. La solution à ce problème est l utilisation d une technologie permettant de faire dialoguer un serveur web et un navigateur de manière asynchrone par l échange de messages au format XML. Cette technologie s appelle AJAX (Asynchronous Javascript And XML) et repose sur l utilisation de Javascript, DHTML et XML. L intérêt d un système AJAX est que le temps de traitement sur le serveur d une requête est beaucoup plus rapide que la création et l envoi d une page web complète. Le serveur d applications se retrouve moins chargé permettant ainsi la mise en place de mécanismes de mise à jour automatique. 50

56 10.3. INTÉGRATION DANS OFBIZNÉOGIA Cette interface permet de charger une configuration (MrpRun), d exécuter le MRP, de suivre en «temps-réel 1» l état du MRP (niveau de nomenclature courant, article courant, pourcentages d avancement, messages d erreur,...), d annuler son exécution ou bien de la recommencer. À terme, cette interface sera présentée automatiquement à l utilisateur lors du lancement du MRP depuis l interface principale. Fig Interface de contrôle du MRP Ci-dessous, un exemple de message XML échangé entre le serveur d applications et le navigateur du client pour récupérer l état du MRP. <MrpState status="running" duration="1650" currentproduct="table" currentbomlevel="1" productprogress="0.2" totalprogess="0.1" isinitialized="true" isrunning="true" iscancelled="false" isrestartable="false"> <Error message="unable to find routing of product [TABLE]"> </MrpState> Fig Sérialisation d un MrpState 1 toutes les secondes 51

57 Chapitre 11 Développement du CRP La mise en oeuvre d un CRP nécessite des structures de données adaptées à la planification des capacités de production et à la planification des charges engendrées par le MRP sur l outil de production. D une part, le CRP s exécute sur un temps discret décomposé en périodes, et pour chacune d entre-elles, il faut être capable de déterminer la capacité et la charge de chaque ressource. D autre part, toute planification de l utilisation d une ressource doit se faire via le CRP pour conserver la cohérence et la justesse de ces données. Le développement du CRP s articule autour de la mise au point des structures de données et de la reprise de tous les algorithmes de planification de ressources d OfbizNéogia pour qu ils utilisent ces structures de données. Enfin, le dernier élément important dans le développement du CRP est la réalisation de l algorithme de planification à capacité finie qui sera à la base de l algorithme de lissage par la suite. 52

58 11.1. STRUCTURES DE DONNÉES DU CRP 11.1 Structures de données du CRP Le CRP sera implicitement utilisé par le MRP lorsque ce dernier créera des ordres de fabrication. Les structures de données ne doivent donc pas pénaliser l exécution du MRP. Ce type de contrainte conduit généralement à une complexité spatiale plus importante ce qui peut impacter sur les performances de l ensemble à cause de l accès à la base de données. Il faut donc développer des structures avec un bon compromis entre temps de recherche et temps de chargement Gestion de plannings Lors de l élaboration de la solution, il a été noté que le CRP devait fonctionner sur une base de temps périodique. Il faut, en particulier, être capable de récupérer la capacité et la charge d une ressource pour une période donnée. En outre, pour éviter d avoir à recalculer des données périodiques constantes 1 telle que la capacité d une ressource, ces données doivent être calculées une fois puis conservées dans une structure de données adaptée que nous appelerons Planning. Or ce type de structure n existe pas dans OfbizNeogia, il a donc fallut les développer. Dans ce type de situation, il faut en profiter pour modéliser une structure qui puisse être réutilisée par d autres modules du progiciel. Ainsi, la modélisation réalisée pour conserver des données périodiques (cf. Figure 11.1) a pu être réutilisée par l équipe chargée de la modélisation des prévisions de vente et du plan directeur de production. Un planning est défini par une périodicité et par un ensemble de périodes de temps successives pas nécessairement de tailles fixes (PlanningPeriod). Par exemple, dans un planning avec une périodicité mensuelle, on peut trouver des périodes de 29, 30 et 31 jours. Enfin, l attribut referencedate définit la date de début de la période 0. Fig Modélisation UML de la notion de planning Le fait d avoir modélisé les périodes d un planning par une interface permet d utiliser le design pattern Factory du côté du planning. Ainsi les développeurs souhaitant utiliser cette modélisation sont libres de choisir les données périodiques à conserver, du moment qu il respecte la spécification de l interface. Un exemple d utilisation de cette méthode est la modélisation du planning d une ressource dans la partie suivante. 1 qui ne changent pas au cours d une période 53

59 11.1. STRUCTURES DE DONNÉES DU CRP Les méthodes permettant de calculer la durée d une période n apparaissent pas sur le diagramme de classes ci-dessus. Néanmoins, elles sont centralisées au niveau de l entité Planning- Periodicity pour faciliter la réutilisation de cette entité dans d autres modules. La gestion des périodes d un planning n est pas forcément simple quand les périodes sont de tailles différentes. Pour simplifier cette tâche, deux outils ont été introduits : PeriodIterator et PlanningPeriodIterator. Le premier permet de manipuler des périodes de temps de durée variable. Le second hérite du premier et est lié à un planning. Il permet d énumérer les périodes d un planning sans avoir besoin de lire la base de données. Fig Modélisation UML de la notion de planning 54

60 11.1. STRUCTURES DE DONNÉES DU CRP Modélisation des capacités d une ressource Maintenant qu une structure de données adaptée à la gestion de données périodiques est disponible, elle va être spécialisée pour la modélisation des capacités d une ressource. Ainsi l entité ResourcePlanning hérite de Planning pour gérer des périodes de type ResourcePlanningPeriod. Une période est définie par sa date de début et sa durée. Les attributs StartOffset et availability indiquent respectivement le début et la durée de disponibilité de la ressource dans la période considérée. Enfin les attributs ressourcequantity et maxresourceqty donnent le nombre de d unités de ressource disponible ainsi que la quantité maximum qu il est possible d utiliser pour la période. Fig Modélisation UML des capacités des ressources Fig Schéma simplifié d un ResourcePlanning Calcul de la capacité d une ressource pour une période : capacity = availability resourcequantity Un planning étant potentiellement infini, ses périodes sont créées à la demande lorsque l application tente d accèder à l une d entre-elles. Lors de leur initialisation, les capacités sont 55

61 11.1. STRUCTURES DE DONNÉES DU CRP fixées à partir du calendrier industriel de la ressource. Le décideur pourra ensuite les modifier pour intégrer des heures supplémentaires, par exemple. Une difficulté qui est apparue lors de l élaboration du CRP, est que les périodes d un planning ne correspondent pas forcément à celle du calendrier industriel. Il faut alors effectuer des estimations qui nuisent un peu à la précision de l ensemble. Ainsi la date de début de disponibilité d une ressource est calculée de la manière suivante : (duration availability) startoffset = 2 Comme indiquée en introduction, le gain de temps gagné sur le calcul des capacités d une ressource a des répercutions sur la quantité de données à extraire depuis la base de données. Pour pallier ce problème, un mécanisme de caches a été mis en place pour conserver les plannings et leurs périodes en mémoire le temps d un traitement important tel que l exécution du MRP ou le lissage des charges. Ces caches peuvent être paramétrés pour fonctionner dans un mode LRU (Last Recent Use). Cependant, pour conserver la cohérence des données entre cache et base de données, les modifications de plannings doivent se faire exclusivement via le CRP. C est pourquoi toutes les opérations de planification sont centralisées dans ce module Modélisation des charges d une resources Le but de cette modélisation est d être capable à tout moment, de calculer simplement la charge d une ressource pour une période donnée. De plus, pour l algorithme de lissage, il faut être capable de récupérer les opérations qui utilisent cette ressource et de distinguer la charge ferme de la charge planifiée. Pour atteindre ces objectifs, il suffit de lier l utilisation des ressources (TaskResourceFulfil) aux RessourcePlanningPeriod correspondant. Fig Modélisation UML des charges des ressources À l heure actuelle, l entité ResourcePlanningPeriod ne contient aucun champs concernant la charge de la période car il est facile de l obtenir en sommant le champs duration de chaque ResourceUsage associé à la période. S il s avère à l usage que ce calcul est finalement coûteux, il est prévu d ajouter les champs plannedload, closedload et totalload à l entité ResourcePlanningPeriod. Ces champs devront être mis à jour après chaque planification. 56

62 11.2. ALGORITHMES DE PLANIFICATION 11.2 Algorithmes de planification Cette partie présente les différents algorithmes de planification mis en oeuvre dans le cadre du CRP. Ces algorithmes se basent sur les structures de données décrites précédemment, et sur celles du module de gestion d atelier. En effet, ils portent sur la planification des ordres de fabrication et de leurs opérations, ainsi que sur la planification de l utilisation des ressources. Afin de rester strictement dans le cadre du couple MRP-CRP, les algorithmes présentés ne fonctionnent qu en planification arrière (planification à partir des dates de fin) bien qu ils intègrent en réalité aussi la planification avant. Par contre, ils intègrent la prise en compte des capacités de production Algorithme de planification d un OF L algorithme de planification d un ordre de fabrication est très simple puisque ce n est pas à ce niveau que l on traite la planification multi-ressources ou que l on prend en compte les capacités. Ces problèmes seront traités dans les parties suivantes, à savoir la planification d une opération et la planification de l utilisation d une ressource. Dans le cas du MRP, le but de la planification d un OF est de calculer sa date de lancement à partir de sa date de fin estimée. Pour obtenir ce résultat, il suffit simplement de planifier chacune de ses opérations en les prenant dans l ordre inverse de leur réalisation. Ainsi, la date de début calculée d une opération devient la date de fin estimée de l opération précédente de l OF. La planification d un OF entraîne la mise à jour de ses besoins en composants, et par la même occastion, la mise à jour des mouvements de stock planifiés qu il génère. Ces mises à jour s effectue automatiquement via un mécanisme d évènements interne à d Ofbiz appelé SECA qui déclencle l appel des services de mise à jour. C est pourquoi ils n apparaissent pas dans l algorithme. Le rôle de la donnée BoundDate est de fixer une date limite de planification. Dans le cadre de la planification d un OF par le MRP, cette date pourrait être la date de début de l horizon de planification du MRP. Nous verrons son utilité dans la section suivante. 57

63 11.2. ALGORITHMES DE PLANIFICATION Algorithme de planification d une opération La principale difficulté dans la mise en oeuvre de la planification d une opération est le fait qu elle puisse nécessiter plusieurs ressources. Dans ce cas, toutes les ressources doivent être disponibles pendant l opération. Par ailleurs, ces ressources peuvent ne pas avoir le même type de planning ce qui rend la recherche de périodes de disponibilité communes encore plus délicate. Pour comprendre la difficulté de l algorithme à mettre en oeuvre, nous allons nous basé sur un exemple de planification d une opération nécessitant trois ressources. Fig Exemple de planification d une opération Dans l exemple ci-dessus (Figure 11.6), on commence par planifier la ressource dont l indicateur valueforplanification est à 1 conformément aux spécifications du module de gestion d atelier. L utilisation de cette ressource détermine ainsi la position de l opération dans le temps. Ensuite, il ne reste plus qu à planifier l utilisation des ressources restantes dans l intervalle de temps définit par l utilisation de la première ressource. Or dans cette exemple, il n est pas possible de trouver une planification de l utilisation de la ressource 3 qui satisfasse la contrainte posée par cet intervalle. Dans ce cas, on annule les planifications réalisées et on recommence la planification de la première ressource à partir de la période précédente de son planning (Figure 11.7). Fig Exemple de planification d une opération Pour éviter, un temps de recherche infini lorsque les plannings des ressources sont incompatibles ou lorsqu en mode planification à capacité finie les ressources sont surchargées, une date limite a été introduite. Elle définit la date de début minimale de l utilisation de toute ressource. 58

64 11.2. ALGORITHMES DE PLANIFICATION 59

65 11.2. ALGORITHMES DE PLANIFICATION Algorithme de planification de l utilisation d une ressource L algorithme de planification de l utilisation d une ressource est important car c est à ce niveau que les structures de données du CRP vont être utilisées pour prendre en compte la capacité et la charge d une ressource. Il consiste à rechercher dans le planning d une ressource un emplacement compatible avec l utilisation prévue de la ressource. On entend par compatible, un emplacement situé dans l espace de recherche, qui remplit les besoins en capacité et quantité de ressource. L espace de recherche est définit par l intervalle [BoundDate, DueDate]. La planification à capacité finie est activée lorsque finitecapacity est à 1. L élément important de cet algorithme est l objet Period qui correspond à l entité ResourcePlanningPeriod. C est à partir de cet objet que l on récupére la capacité disponible d une ressource et que l on met à jour sa charge. 60

66 11.3. CONSÉQUENCES DE LA PLANIFICATION À CAPACITÉ FINIE 11.3 Conséquences de la planification à capacité finie Dans cette partie, on ne s intéresse qu à la planification des ressources car c est le seul endroit où les capacités de production vont intervenir. Une caractéristique principale de cette implémentation de la planification à capacité finie est l allongement du temps nécessaire à la réalisation d un ordre de fabrication. D une part, à cause de la prise en compte des capacités de production mais aussi parce qu on ne doit plus fixer des dates de début et de fin d utilisation d une ressource. C est le rôle d un algorithme d ordonnancement et pas celui du CRP, qui doit uniquement vérifier que les capacités sont disponibles pour une période donnée. Ainsi, ne sachant pas quel sera l ordonnancement utilisé, les dates de début et de fin d utilisation d une ressource sont bornées par les dates de début et de fin des périodes utilisées. Fig Exemple de planification à capacité finie Allongement du temps nécessaire à la réalisation d un ordre de fabrication car des opérations ne peuvent plus utiliser une même ressource pendant une même période. En effet, lorsque l on planifie l utilisation d une ressource on sait pendant quelles périodes elle va être utilisée mais pas ses dates de début et de fin. Donc pour éviter tout recouvrement, l algorithme de planification à capacité finie s assure qu il y a toujours une période d écart pour l utilisation successive d une ressource par un même OF. Fig Allongement du temps nécessaires à la réalisation d un OF Enfin, allongement du temps nécessaire à la réalisation d un ordre de fabrication car si la date de fin d utilisation d une ressource tombe au milieu d une période on est obligé de l avancer à la période précédente. En effet, ne sachant pas quel sera l ordonnancement utilisé, il n est pas possible d assurer que l utilisation de la ressource sera bien terminée à la date de fin indiquée. 61

67 11.4. INTÉGRATION AVEC LE MODULE DE GESTION D ATELIER Fig Allongement du temps nécessaires à la réalisation d un OF Le principal défaut de la méthode de planification à capacité finie utilisée est qu elle n est pas toujours fiable. Ce n est pas parce que la capacité nécessaire est disponible que la solution est réalisable car l algorithme de planification ne prend pas en compte la quantité de ressource disponible. Ainsi, si 5 ressources identiques sont disponibles pendant 24h et que deux opérations nécessitent respectivement 4 ressources pendant 24h et 3 ressources pendant 5h ; la solution n est pas réalisable car bien que la charge soit inférieure à la capacité, le nombre de ressources nécessaires à chaque instant n est pas suffisant Intégration avec le module de gestion d atelier Lors de l élaboration de la gestion de planning des ressources, nous avons vu que pour que le CRP soit fiable, il faut que toute planification de l utilisation d une ressource se fasse par son intermédiaire. C est pourquoi, les algorithmes de planification d OFs et d opérations existants ont été entièrement repris pour intégrer l utilisation des plannings. Cependant, les algorithmes de planification du module de gestion d atelier fonctionnent en planification avant (forward scheduling 2 ) contrairement au MRP qui utilise la planification arrière (backward scheduling 3 ). Ainsi, l intégration du CRP dans ce module a dû être réalisée en conservant le mode de planification initial. Par conséquent, tous les algorithmes présentés précedemment intègrent la notion de sens de planification. De ce fait, la planification manuelle d un OF bénéficie du CRP et de ses mécanismes de détection de surcharge. 2 planification à partir des dates de début 3 planification à partir des dates de fin 62

68 Cinquième partie Bilan 63

69 Chapitre 12 Bilan du projet 12.1 État d avancement Les modules prévus dans la décomposition fonctionnelle présentée dans le chapitre «Solution mise en oeuvre», n ont pas encore été tous implémentés en raison des temps de développement requis pour une application de cette ampleur et de certains problèmes rencontrés. Ainsi, l état d avancement du projet est estimé à 70% réalisé. En particulier, l algorithme de lissage des charges n a pu être terminé à temps à cause de problèmes rencontrés tardivement au niveau la planification multi-ressources à capacité finie et au niveau de la replanification des besoins en composants. En revanche, le reste des fonctionnalités annoncées sont fonctionnelles. Ainsi, OfbizNéogia dispose d un MRP couplé à CRP ce qui le classe désormais dans la catégorie des MRP Problèmes rencontrés Problèmes fonctionnels Problème lié à la replanification des besoins L algorithme d ajustement charge-capacité prévu, peut être amené à décaler des OF afin de faire diminuer les charges pesant sur les ressources. Or, ces décalages peuvent avoir des conséquences sur les niveaux de stock qui n avaient pas été prévues lors de l élaboration de l algorithme. En effet, si l opération que l algorithme souhaite décaler nécessitait des besoins en composants, et que ces besoins ont généré des propositions d OF, alors le décalage va bien décaler les besoins en composant mais ne va pas annuler les OF proposés. On risque ensuite d avoir une hause des niveaux de stock et une utilisation inutile des ressources de l atelier. Ces conséquences ne remettent pas en cause l algorithme de lissage mais il faudra mettre en place un mécanisme pour détecter les propositions inutiles lors de l appel au MRP chargé de refaire la planification des besoins en composants après le décalage d une opération. À l heure actuelle, deux solutions sont envisagées pour résoudre ce problème : utiliser un MRP différentiel qui ajusterait les propostions existantes ; 64

70 12.2. PROBLÈMES RENCONTRÉS développer un mécanisme de «pegging ([GP75])» permettant de retrouver l origine d une proposition et de l ajuster si le besoin n existe plus. Probléme lié à la planification multi-ressources à capacité finie L algorithme de planification d une opération, lorsqu il est utilisé en planification à capacité finie, présente un risque de ne jamais trouver de solution du fait des décalages de temps introduits par la planification à capacité finie (cf. Section 11.3). Pour éviter un bouclage infinie, des dates limites de planification ont été introduites cependant cette amélioration ne résoud pas le problème. Il existe pourant une solution partielle à ce problème, qui consisterait à diminuer la durée de l opération pour augmenter les chances de trouver une configuration valide. Le seule moyen disponible pour faire baisser la durée d une opération est de diminuer la quantité à produire en avançant une partie de la production. Cette solution obligerait l algorithme de lissage à ne plus considérer uniquement le décalage d une opération mais aussi le décalage des quantités à produire. À ce stade, il serait peut-être plus simple de revoir le plan directeur de production plutôt que du perdre du temps à trouver une configuration valide Problèmes techniques Le principal problème technique rencontré concerne la concurrence de transactions avec la base de données lors de l exécution du MRP. Par défaut, un service Ofbiz s exécute dans une transaction qui assure l isolation par rapport à des requêtes s exécutant sur la base de données. Or le MRP étant un processus long et une transaction pouvant poser des verrous sur des tables, des situations d interblocage survenaient lorsque le thread du MRP et celui du MrpController tentaient d accéder à l entité MrpRun Temps de développement Les temps de développements d une application dans un ERP comme Ofbiz, sont plus longs en raison de l architecture et de la taille de ce type de projet. Par exemple, il est quasiment impossible d utiliser un débogueur avec Ofbiz. Il faut alors utiliser des logs pour tracer le contenu des variables et l exécution des algorithmes. De même, la mise en place de procédures de tests est rendue délicate en raison de l omniprésence de la base de données et du temps de lancement de l ERP qui oscille entre 30 et 90 secondes avant d obtenir la main sur le système. Pour ce projet, j au eu la chance de pouvoir travailler directement sur le dépot CVS contenant les sources d OfbizNéogia. J avais ainsi accès à un système de suivi des modifications du projet ce qui me permettait de suivre l évolution des différents modules nécessaires au MRP. En contrepartie, il fallait éviter de «casser» le projet en «commitant» des développements ne compilant pas. Il était donc nécessaire de passer un certain temps à vérifier que les modifications appportées au projet n allaient pas empêcher les contributeurs du projet de travailler. 65

71 12.3. AMÉLIORATIONS POSSIBLES 12.3 Améliorations possibles L infrastructure du MRP et du CRP mise en place fournit une base stable pour de futurs développements. Cependant, le temps de mise en oeuvre de cette infrastructure a consommé du temps de développement initialement prévu pour d autres aspects du projet. Actuellement, le CRP ne dispose d aucune interface permettant au décideur de visualiser les dépassements de capacité car les scénarios ne sont pas encore complétement définis. Il faudrait, en particulier, qu il puisse faire les ajustements de capacité des ressources directement depuis l interface du CRP avant de laisser la main à l algorithme de lissage. Un point important qui n a pas été réalisé faute de temps, est la réalisation d un jeu de données conséquent pour tester les performances du couple MRP-CRP. Jusqu à présent, les développements ont porté sur la réalisation d un système fonctionnel sans prise en compte des performances. La seconde phase des développements consistera donc à améliorer le système pour atteindre des performances correctes pour un système MRP-1. Une possibilité est de développer un générateur de nomenclatures, de gammes et mouvements de stocks planifiés pour tester le système aux limites. 66

72 Chapitre 13 Conclusion Bien que ce projet ne soit pas complétement terminé, les éléments développés sont fonctionnels et sont d ores et déjà présentés aux futurs clients de Néréide lors des démonstrations du progiciel. De même, certaines modélisations commencent à être réutilisées dans d autres parties du progiciel, notamment la gestion de planning. Ce projet est le plus important que j ai été amené à développer jusqu à présent. Il m a permis de découvrir la gestion de production, la mise en oeuvre d un MRP et les différentes problématiques liées à ce type d application. Ce fut aussi l occasion de travailler sur un projet international, notamment par l envoi de rapports de bogue et de corrections directement aux mainteneurs américains d Ofbiz. Bien qu ayant déjà travaillé sur OfbizNéogia au cours d un stage précédent le PFE, ma plus grande difficulté a été d avoir une vision globale du projet durant les phases de conception. Concevoir un système le plus ouvert possible pour permettre facilement l ajout et/ou la réutilisation de fonctionnalités n est pas une tâche simple quand tous les éléments ne sont pas clairement définis. D ou un temps non négligeable passé à comprendre le fonctionnement du couple MRP-CRP. De plus, le développpement d un système ERP est complétement différent du développement d une application isolée du fait que plusieurs utilisateurs peuvent être connectés au système à tout instant, que les ressources doivent être partagées, que tout passe par une base de données, etc. Enfin, ce projet ne s arrête pas là puisqu il fait l objet d un stage de fin d étude chez Néréide. Ce stage devrait me permettre de terminer les fonctionnalités manquantes pour obtenir un MRP-2, à savoir la mise en oeuvre de l algorithme d ajustement charge-capacité. 67

73 Sixième partie Annexes 68

74 Annexe A Modélisation des données techniques dans OfbizNeogia 69

75 Annexe B Modélisation des ordre de fabrication dans OfbizNeogia 70

76 Annexe C Modélisation du MRP réalisé 71

77 Annexe D Modélisation des charges/capacités des ressources 72