Rapport de projet de fin d`étude Développement d`un MRP `a

Transcription

Université François Rabelais Tours
École Polythechnique Universitaire - Département Informatique
64, avenue Jean Portalis
37200 Tours
Rapport de projet de fin d’étude
Développement d’un MRP à capacité finie pour l’ERP
libre OfbizNéogia
Encadrants :
SOUKHAL Ameur
HEINTZ Olivier
Étudiant :
GORON Peter
EPU-DI 3e année
Année 2004-2005
Table des matières
I
3
Environnement technique du projet
1 Présentation d’Ofbiz
1.1 Une architecture . . . . .
1.2 Un framework . . . . . . .
1.2.1 L’Entity Engine .
1.2.2 Le Service Engine
1.2.3 Le Control Servlet
1.3 Des applications . . . . .
.
.
.
.
.
.
4
5
6
6
7
7
8
2 Présentation de Néogia
2.1 Les enjeux de la génération de code . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2 Les applications Néogia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
10
11
II
12
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
État de l’art
3 Planification de la production
3.1 Présentation des systèmes MRP .
3.1.1 Historique . . . . . . . . .
3.1.2 Pré-requis pour la mise en
3.1.3 La logique du MRP . . .
3.2 Défauts des systèmes MRP . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
13
14
14
14
15
16
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
17
18
18
18
19
19
20
20
22
22
23
charge
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
24
25
25
. . . . . . .
. . . . . . .
oeuvre d’un
. . . . . . .
. . . . . . .
. . . .
. . . .
MRP
. . . .
. . . .
4 Planification des capacités de production
4.1 Planification des besoins en moyens de production
4.1.1 Principe . . . . . . . . . . . . . . . . . . . .
4.1.2 Mise en oeuvre . . . . . . . . . . . . . . . .
4.2 Validation du plan directeur de production . . . .
4.2.1 Approche par facteurs globaux . . . . . . .
4.2.2 Approche par feuille de capacité . . . . . .
4.2.3 Approche par profil de ressource . . . . . .
4.3 Planification des besoins en capacité de production
4.3.1 Calcul de la charge . . . . . . . . . . . . . .
4.3.2 Résultats du CRP . . . . . . . . . . . . . .
5 Techniques de lissage de
5.1 Lissage en parallèle . .
5.2 Lissage en série . . . .
5.3 Limitations . . . . . .
.
.
.
.
.
.
.
.
.
.
6 Conclusion de l’état de l’art
26
III
27
Analyse de l’existant
7 Étude du MRP existant
7.1 Données manipulées par le MRP . . . . . . . . . . . . . . . . . . . . . . . . . . .
ii
28
28
7.2
7.3
Fonctionnalités . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Particularités . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8 Module de gestion de production
8.1 Gestion des données techniques . . . . .
8.1.1 Les ressources . . . . . . . . . . .
8.1.2 Le calendrier industriel . . . . .
8.1.3 Les gammes opératoires . . . . .
8.1.4 Les opérations . . . . . . . . . .
8.1.5 Les nomenclatures . . . . . . . .
8.2 Gestion d’atelier . . . . . . . . . . . . .
8.2.1 Les ordres de fabrication . . . . .
8.2.2 Programmation de la production
IV
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Développements réalisés
29
29
30
30
30
30
31
32
32
33
33
34
35
9 Solution mise en oeuvre
9.1 Présentation de la solution . . . . . . .
9.1.1 Principe . . . . . . . . . . . . .
9.1.2 Place du décideur . . . . . . .
9.2 Algorithme de lissage en série simplifié
9.3 Analyse des besoins fonctionnels . . .
9.3.1 MRP . . . . . . . . . . . . . .
9.3.2 CRP . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
36
36
36
37
38
39
39
40
10 Développement du MRP
10.1 Modélisation du MRP . . . . . . . . . . . . . . . . . . .
10.1.1 Les entrées . . . . . . . . . . . . . . . . . . . . .
10.1.2 Les sorties . . . . . . . . . . . . . . . . . . . . . .
10.1.3 Structures de contrôle du MRP . . . . . . . . . .
10.2 Algorithmes mis en oeuvre . . . . . . . . . . . . . . . . .
10.2.1 Algorithme du MRP mono-article mono-niveau .
10.2.2 Algorithme du MRP mono-article multi-niveaux
10.2.3 Algorithme du MRP multi-articles . . . . . . . .
10.3 Intégration dans OfbizNéogia . . . . . . . . . . . . . . .
10.3.1 Services du MRP . . . . . . . . . . . . . . . . . .
10.3.2 Interfaces graphiques du MRP . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
41
41
41
43
44
46
46
47
48
49
49
50
.
.
.
.
.
.
.
.
.
.
52
53
53
55
56
57
57
58
60
61
62
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
11 Développement du CRP
11.1 Structures de données du CRP . . . . . . . . . . . . . . . . . . .
11.1.1 Gestion de plannings . . . . . . . . . . . . . . . . . . . . .
11.1.2 Modélisation des capacités d’une ressource . . . . . . . . .
11.1.3 Modélisation des charges d’une resources . . . . . . . . .
11.2 Algorithmes de planification . . . . . . . . . . . . . . . . . . . . .
11.2.1 Algorithme de planification d’un OF . . . . . . . . . . . .
11.2.2 Algorithme de planification d’une opération . . . . . . . .
11.2.3 Algorithme de planification de l’utilisation d’une ressource
11.3 Conséquences de la planification à capacité finie . . . . . . . . . .
11.4 Intégration avec le module de gestion d’atelier . . . . . . . . . . .
iii
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
V
Bilan
12 Bilan du projet
12.1 État d’avancement . . . . . . . .
12.2 Problèmes rencontrés . . . . . . .
12.2.1 Problèmes fonctionnels . .
12.2.2 Problèmes techniques . .
12.2.3 Temps de développement
12.3 Améliorations possibles . . . . .
63
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
64
64
64
64
65
65
66
13 Conclusion
67
VI
68
Annexes
A Modélisation des données techniques dans OfbizNeogia
69
B Modélisation des ordre de fabrication dans OfbizNeogia
70
C Modélisation du MRP réalisé
71
D Modélisation des charges/capacités des ressources
72
Glossaire
74
Bibliographie
75
iv
v
Remerciements
Mes remerciements s’adressent en premier lieu à Ameur SOUKHAL et Olivier Heintz pour
leur disponibilité et pour m’avoir laissé une trés grande autonomie pour mener ce projet. Je
souhaiterais aussi remercier toute l’équipe Néréide pour leur collaboration sur ce projet.
1
Introduction
Ce projet, en collaboration avec la société Néréide, porte sur la réalisation d’un MRP
(Material Requirements Planning) à capacité finie pour l’ERP (Enterprise Resource Planning)
libre OfbizNéogia. Il s’inscrit dans la continuité d’un projet de fin d’étude réalisé en 2004 par
Thierry Grauss, qui portait sur la réalisation d’un MRP à capacité infinie.
Néréide est une jeune société de services en logiciels libres, spécialisée dans l’intégration
de progiciels de gestion. L’objectif de ce projet est donc d’ajouter au MRP de son progiciel,
OfbizNéogia, la prise en compte des capacités de production lors de la planification des besoins
en composants. Cette prise en compte des capacités est particulièrement importante pour assurer
que les délais de livraison seront respectés par la planification proposée par le MRP.
Ce rapport se divise en cinq parties. La première présente l’environnement technique dans
lequel s’est effectué ce projet. La seconde est un état de l’art sur les MRP et les problèmes de
gestion de capacité de production, elle permet ainsi de situer la problématique du projet et les
différentes solutions envisageables. La troisième partie est une étude de l’existant, c’est-à-dire
une étude des bases à partir desquelles les développements doivent prendre lieu. Puis la suivante
présentera la solution mise en oeuvre et les développements réalisés pour mener ce projet à
son terme. Enfin la dernière partie porte sur le bilan du projet, aussi bien sur l’adéquation des
résultats par rapport aux objectifs que sur les acquis.
2
Première partie
Environnement technique du projet
3
Chapitre 1
Présentation d’Ofbiz
Open For Business, ou Ofbiz, est un projet de progiciel de gestion intégré (PGI) libre initié
par deux développeurs américains, Andy Zeneski et David E. Jones, en mai 2001. L’objectif
de ce projet est de fournir un ensemble de composants homogènes permettant de développer
aisément et rapidement des logiciels libres de gestion. À terme, il est prévu d’obtenir tous les
composants nécesssaires à un PGI inté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 qualité et ils
assurent l’indépendance du projet. De même, Ofbiz respecte de nombreux standards pour
garantir un maximum de compatibilité avec les systèmes existants et futurs, notamment J2EE
et XML. Ce dernier est largement utilisé dans tout le projet pour décrire les données et les
traitements.
Par ailleurs, le code source du projet est publié sous la licence MIT qui est libre et permissive, c’est-à-dire qu’elle ne fixe aucune obligation et/ou interdiction quant à l’utilisation, la
modification, l’extension et la commercialisation du logiciel. Grâce à l’ouverture du code, une
véritable communauté d’utilisateurs et de développeurs s’est formée. Cette dernière assure ainsi
la réactivité et la qualité du projet.
Cependant, de par sa taille et sa complexité, ce type de logiciel nécessite de gros investissements humains, matériels et financiers pour son développement mais aussi pour être reconnu.
Les auteurs initiaux ont donc créé une société, Undersun Consulting, qui offre des services autour
d’Ofbiz tout en les rémunérant pour leur travail de développement. Plusieurs sociétés du même
type se sont créées un peu partout dans le monde dont Néréide pour la France. Elles participent
4
1.1. UNE ARCHITECTURE
ainsi au projet en tant que sponsors. Généralement, ces sociétés proposent quatre types de
services :
– l’installation et l’adaptation si nécessaire d’Ofbiz ;
– le développement d’extensions spécifiques à l’entreprise ;
– la maintenance du système ;
– la formation des utilisateurs.
1.1
Une architecture
Ofbiz est une application java client-serveur compatible avec la spécification J2EE qui définit
une architecture logicielle standard. On retrouve ainsi les trois éléments caractéristiques d’une
architecture 3-tiers :
– les clients : ici des clients légers, typiquement des machines peu puissantes disposant d’un
navigateur internet ;
– un serveur exécutant les différentes applications Ofbiz ;
– et une ou plusieurs bases de données stockant le système d’information de l’entreprise.
Fig. 1.1 – Architecture n-tiers d’Ofbiz
Néanmoins, l’architecture d’Ofbiz peut aussi être considéré comme une architecture n-tiers
car elle peut faire appel à des applications externes via des services. Ces derniers ne sont pas
forcément exécutés sur la même machine, on les appelle alors WebServices. Ce type d’architecture
présente de nombreux avantages. Elle permet de distribuer plus librement la logique applicative,
ce qui facilite la répartition de la charge entre tous les niveaux. Elle facilite l’intégration de
l’application avec celles déjà existantes. Enfin, elle permet d’accéder à un très grand nombre de
fonctionnalités.
Fig. 1.2 – Architecture J2EE d’Ofbiz
Une des caractéristiques principales d’Ofbiz est la modularité de son architecture. En effet,
tout est composant. Cette approche favorise une meilleure réutilisation des composants logiciels,
5
1.2. UN FRAMEWORK
un développement modulaire donc plus rapide et enfin une meilleure qualité. Ce type d’architecture permet aussi de remplacer un composant par un autre très facilement dans le cas où il
existe plusieurs implémentations différentes.
Ofbiz se décompose en deux parties : le serveur et les composants. Le serveur, ou base,
propose un environnement d’exécution homogène et performant pour les applications qu’il fait
tourner. Il fournit tout un ensemble de mécanismes de gestion de cache et de pools de connexions
qui permettent une meilleure montée en charge et une meilleure réactivité du système.
Les composants, quant à eux, représentent les plus petites briques logicielles géré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 à : un jeu de données, un modèle
de données, des services, une ou plusieurs applications web, du code java. Généralement, un
composant est spécialisé pour une fonctionnalité donnée.
L’architecture d’Ofbiz se décompose en une multitude de composants qui, regroupés ensemble, forment un PGI complet. Toutefois, tous n’ont pas le même rôle au sein du PGI, c’est
pourquoi on les classe selon trois niveaux d’abstraction :
– le framework qui permet de développer des applications métier rapidement ;
– les applications de base que l’on retrouve dans tout type d’organisation ;
– les applications de haut-niveau et/ou applications métier.
1.2
Un framework
Ofbiz est en premier lieu un «framework d’application d’entreprise» dans lequel chaque
composant représente une brique logicielle pouvant être réutilisé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.
1.2.1
L’Entity Engine
L’Entity Engine est un composant Ofbiz qui se charge de la gestion des données de tous
les autres composants Ofbiz. Les données sont représentées selon un modèle Entité-Relation
largement utilisé dans les applications d’entreprise et compatible avec la plupart des bases de
données relationnelles. Le principal objectif de ce composant est d’éliminer tout code spécifique
à la persistance des données dans un système transactionnel. Ses principales caractéristiques
sont :
– accès aux données via une interface unique, le «GenericDelegator» ;
– supporte l’accès transparent à plusieurs base de données ;
– les entités sont définies dans de simples fichiers XML ;
– tous les types java de base ont un équivalent en base de données ;
– supporte les transactions distribuées ;
– suppporte un mécanisme de trigger appelé «EECA1 » même si le SGBD sous-jacent n’implémente
pas cette fonctionnalité.
1
Entity Event-Condition-Action
6
1.2. UN FRAMEWORK
1.2.2
Le Service Engine
Le Service Engine est l’équivalent de l’Entity Engine pour tous les traitements des composants
Ofbiz. Les traitements sont appelés Services et peuvent être exécutés localement ou à distance.
Le principal intérêt de ce composant est qu’il permet de lancer des services sans avoir besoin de
connaı̂tre leur localisation et leur implémentation. C’est le ServiceDispatcher qui se charge alors
de trouver l’implémentation du service et de son exécution. Un autre intérêt est la possibilité de
rendre disponible tout service Ofbiz vers l’extérieur.
Les services sont définis dans des fichiers XML dans lesquels il faut indiquer pour chaque
service :
– son nom ;
– son implémentation (java, beanshell, minilang, etc) ;
– sa localisation ;
– la méthode à invoquer lors de son appel ;
– la nécessité ou non d’être authentifié pour pouvoir l’appeler ;
– ses paramètres d’entrée ;
– ses paramètres de sortie.
Un service est un traitement qui prend des paramètres en entrée et des paramètres en
sortie. Ces paramètres sont vérifiés avant et après l’appel d’un service. Le traitement peut
être asynchrone ou synchrone. L’accès aux entités à partir d’un service se fait automatiquement
par l’intermédiaire d’une transaction ainsi en cas d’échec du service, la cohérence des bases de
données est conservée.
1.2.3
Le Control Servlet
Le ControlServlet est l’élément clé de la communication entre les utilisateurs et les applications web d’Ofbiz. Implémenté selon le modèle MVC (Modèle-Vue-Controleur), il gère la
boucle d’évènements de l’interface graphique et les différents moteurs de rendu de l’application.
Les réponses aux intéractions de l’utilisateur s’effectuent par l’intermédiaire d’évènements qui
peuvent être implémentés sous la forme de services, de méthodes java, de scripts Beanshell ou
Minilang.
Voici l’ensemble des opérations effectuées suite à une intéraction avec l’utilisateur pour lui
afficher une page à 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 requête HTTP au serveur Ofbiz qui est interceptée par Tomcat et transmise au
ControlServlet de l’application web correspondante.
2 Le ControlServlet vérifie si l’URI demandée est définie par l’application. Le cas échéant, il
appelle le ou les événements associés à cette URI. Dans le cas contraire, il renvoie une erreur
au navigateur web de l’utilisateur (Erreur HTTP 404 : page non trouvée).
3 Si l’évènement généré doit appeler un service, il vérifie que les paramètres de la requête
correspondent aux attributs du service.
4 Si l’évènement généré doit appeler un service, il convertit les paramètres de la requête sous
forme textuelle en objets Java correspondant.
5 L’évènement appelle un service ou un gestionnaire d’évènements (méthode java statique).
6 Le service ou le gestionnaire d’évènements peuvent effectuer des actions sur le modèle de
données.
7
1.3. DES APPLICATIONS
Fig. 1.3 – Boucle d’évènement d’une application Ofbiz
7 L’EntityEngine convertit ces actions en requêtes SQL pour le serveur de base de données.
8 Le service ou le gestionnaire d’évènement renvoie le résultat de leur action.
9 L’évènement transmet ce résultat au ControlServlet.
10 À partir du résultat de l’évènement, le ControlServlet sélectionne la vue à afficher et appelle
le moteur de rendu adéquat.
11 À partir de la définition d’une vue, le moteur de rendu construit les différents sous-éléments
de cette dernière.
12 Pour chaque sous-élément, il peut appeler des scripts BeanShell qui récupèrent et mettent en
forme les données à afficher.
13 Pour chaque sous-élément, il appelle le moteur de template qui se charge de générer le code
HTML correspondant.
14 Le moteur de rendu assemble les différents sous-éléments pour former une page web complète.
15 Le ControlServlet transmet la page générée au navigateur web de l’utilisateur.
1.3
Des applications
Un des avantages d’Ofbiz par rapport à d’autres frameworks, est qu’il fournit un certain
nombre d’applications par défaut, qui couvrent quasiment tous les domaines de l’entreprise. Elles
sont livrées prêtes à l’emploi ; il ne reste plus qu’à saisir les données spécifiques à 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 métiers, spécifique à un
secteur d’activité.
8
Chapitre 2
Présentation de Néogia
Bien qu’Ofbiz soit un logiciel écrit en Java, ses auteurs ont privilégié une approche EntitéRelation plutôt qu’une approche orientée objet pour la modélisation du système d’information de
l’entreprise. Ce choix est motivé par un souci de simplicité et de généricité au niveau de la couche
de persistence de données d’Ofbiz (Entity Engine). Cependant, ce type de modélisation présente
le problème de s’attacher plus aux données qu’à la dynamique du système. En conséquence, on
est souvent amené à manipuler directement les tuples de la base de données ce qui peut poser
des problèmes de cohé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 inconvénient, Néréide a entrepris en mai 2004 le développement d’un nouveau
projet appelé Néogia, publié sous la licence GPL. L’objectif de ce projet est de fournir à la
communauté un ensemble d’outils et d’extensions permettant de développer des applications
Ofbiz à l’aide d’une modélisation objet. Ces extensions se présentent sous la forme de composants
Ofbiz générés à partir de diagrammes UML. Le temps gagné par la technique de génération
de code employée dans Néogia permet aux développeurs de se consacrer principalement à la
modélisation de leur application et donc d’augmenter la qualité du produit final.
Les outils de génération de code utilisés par le projet Néogia se basent sur une technologie
mise au point par Code-Lutin, une société de services en logiciels libres nantaise, membre du
réseau Libre-Entreprise et spécialisée dans le développement applicatif en Java. Cette technologie, appelée LutinGenerators, permet à partir d’une modélisation UML stockée dans un fichier
XMI1 de générer n’importe quel type de fichier dès l’instant qu’un générateur correspondant
existe. L’utilisation de cette technologie est le fruit d’une collaboration entre Néréide et CodeLutin dans le cadre d’un transfert de compétences au sein du réseau Libre-Entreprise.
1
Format XML permettant l’échange de modèles UML entre outils de développement logiciel.
9
2.1. LES ENJEUX DE LA GÉNÉRATION DE CODE
2.1
Les enjeux de la génération de code
Les applications d’un progiciel de gestion sont en général très complexes du fait du grand
nombre de fonctionnalités développées et du volume de données très important à manipuler de
façon sécurisée. Ceci implique un temps de développement très long. Or, les problématiques
actuelles de conception de logiciels libres sont en totale oppposition. En effet, du fait du nombre
réduit de développeurs, la conception d’un logiciel libre nécessite de :
– limiter le temps de développement ;
– assurer la souplesse de la plateforme notamment lors d’un changement de technologie ;
– limiter les efforts liés à la maintenance du code.
Dans ce contexte, la génération de code qui consiste à automatiser la création du code dit
d’architecture, est un enjeu important pour les sociétés de services dans le logiciel libre. En effet,
cela permet à la société de concentrer ses efforts non sur le codage d’architecture qui ne sera
pas source de valeur ajoutée mais sur la demande spécifique des clients qui quant à elle, sera
génératrice de valeur ajoutée.
Dans le cas de Néogia, les développements sont réalisées via une approche MDA (Model
Driven Architecture) dans laquelle tout développement passe par la définition d’un modèle UML
qui sera ensuite utilisé pour générer le code de l’application.
Fig. 2.1 – Schéma MDA utilisé par Néogia.
Les générateurs de code de Néogia se chargent de créer toute la couche de persistance de
données entre les objets issus de la modélisation et les entités gérées par l’Entity Engine d’Ofbiz,
et de créer l’interface graphique et les services associés. L’intérêt des composants généré par
Néogia par rapport aux composants Ofbiz est qu’ils sont issus de diagrammes UML et que leur
code est généré à 70 %. L’un des reproches qui est souvent fait aux outils de génération de code
est de ne pas pouvoir distinguer les éléments générés des éléments développés lors de générations
successives. Les générateurs de Neogia ont été conçus pour éviter ce genre de cas en séparant
les parties développées des parties générées.
10
2.2. LES APPLICATIONS NÉOGIA
Voici quelques générateurs fournis par Néogia :
– générateur de services ;
– générateur d’entités ;
– générateur de la couche d’abstraction Objet-Entité ;
– générateur d’interfaces graphiques par défaut pour les objets modélisés ;
– générateur des formulaires de recherche ;
– générateur des fichiers d’internationalisation ;
– etc.
2.2
Les applications Néogia
Afin de démontrer l’efficacité de l’approche MDA pour le développement d’applications
métiers pour Ofbiz, Néréide a recréé entièrement le module de gestion de production d’Ofbiz
via cette approche. Les résultats étant au rendez-vous, les applications de gestion des stocks et
de comptabilité ont elles aussi été refaites. Par la suite, d’autres composants d’Ofbiz ont été
partiellement porté sur cette nouvelle architecture pour faciliter l’intégration des deux projets.
La modélisation UML de ces applications à été realisée à partir de l’expérience acquise lors
de la mise en oeuvre d’autres ERP et également à partir des retours d’expérience de l’utilisation
d’Ofbiz. Pour éviter des confusions entre les applications Ofbiz et les applications Néogia, l’ERP
a été renommer OfbizNéogia.
11
Deuxième partie
État de l’art
12
Chapitre 3
Planification de la production
«La planification de la production vise, pour un horizon de planfication en général de quelques
mois, à optimiser l’utilisation des facteurs productifs disponibles pour la production d’un ou
plusieurs produits répondant à des caractéristiques précises. Il s’agit d’un processus de traitement
d’informations aboutissant à une programmation prévisionnelle s’appuyant sur une dé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 prévoir les approvisionnements, et de planifier l’utilisation des moyens de
production. D’autre part, elle peut aussi être utilisée comme un moyen d’optimiser la production
en cherchant, par exemple, à minimiser les coûts tout en respectant les délais.
Il existe différénts systèmes de planification de production :
– Planification hiérarchisée : méthode utilisée pour élaborer le plan directeur de production,
les produits finis sont regroupés par type et par famille. Elle est adaptée aux productions
de masse. (Hax et Meal, 1975)
– MRP : méthode utilisée pour déduire les besoins en composants à partir de la demande
finale. C’est un système à flux poussé. (J. Orlicky, 1975)
– OPT : méthode de planification traitant différemment les ressources goulots des ressources
non-goulots. Elle ordonnance les ordres de fabrication sur les ressources limitées en priorité.
(E. Goldratt, 1969)
– Kanban : cas particuliers par rapport aux autres méthodes car il n’y a pas véritablement de
planification. Le système de gestion de production s’auto-régule en fonction de la demande.
C’est un système à flux tiré. (T. Ohno, 1959)
Dans la suite de cet état de l’art sur la planification de la production, nous nous intéresserons
uniquement aux méthodes MRP afin de rester dans le cadre du sujet du projet.
13
3.1. PRÉSENTATION DES SYSTÈMES MRP
3.1
3.1.1
Présentation des systèmes MRP
Historique
Les premiers systèmes MRP datent des années 60. Au départ très simples, ils ont continué
à évoluer jusqu’à atteindre un haut niveau de fonctionnalités et d’intégration dans le système
d’information de l’entreprise. Aujourd’hui, on classe les MRP en trois catégories selon leur niveau
de fonctionnalités ([LD98]) :
– MRP0 (1960) : Système qui, à partir des demandes fermes et estimées de produits finis et
des niveaux de stock courants, calcule les besoins en composants (quoi, combien et quand)
permettant de répondre à la demande. Les capacités de production ne sont pas prises en
compte.
– MRP1 (1970) : MRP0 auquel on a rajouté le calcul des charges engendrées sur l’outil de
production par le résultat du MRP. La planification s’effectue toujours à capacité infinie.
– MRP2 (1979) : Évolution du MRP1 qui intègre le calcul des coûts de production et un
algorithme d’ajustement charge-capacité. Ce dernier permet d’ajuster la charge souhaitée
à la charge disponible pour chaque centre de production.
La signification de l’acronyme MRP a aussi changé au cours du temps. Initialement désignant
Material Requirement Planning, il est dévenu Manufacturing Resource Planning pour souligner
le fait que les dernières générations de MRP ne s’appliquent plus uniquement à la planification
des besoins en composant mais aussi à la planification des besoins en ressources.
3.1.2
Pré-requis pour la mise en oeuvre d’un MRP
Une des caractéristiques principales d’un MRP par rapport à une autre méthode de planification de la production, est la masse de données requises pour établir les besoins en composants.
C’est pourquoi, le MRP est presque toujours intégré à une GPAO (Gestion de production assistée
par Ordinateur) ou à un ERP.
Conditions requises pour la mise en oeuvre d’un MRP 0 :
– Existance d’un plan directeur de production : il détermine, pour un horizon de planification
donné, la demande prévisionnelle de chaque produit fini.
– Existance d’une nomenclature complète des composants utilisés : elle permet d’obtenir
pour chaque produit, ses composants ainsi que les quantités nécessaires à son assemblage.
– Existance d’un système d’information fiable sur l’état des stocks : le MRP nécessite une
connaissance correcte de l’état du stock d’un composant (stock disponible, livraisons
attendues, ...) au début ou à la fin de chaque période de l’horizon de planification.
– Existance d’un fichier des délais d’obtention : il est essentiel pour être capable de calculer
les dates de lancement d’un OF ou de passation d’une commande.
– Existance d’un fichier des gammes : les gammes déterminent les ressources utilisées par
les opérations permettant ainsi de calculer les charges.
– Existance d’un fichier des ressources : ce fichier permet d’établir les capacités de production.
14
3.1. PRÉSENTATION DES SYSTÈMES MRP
– Existance d’un fichier des coûts de production et de stockage
– Existance de fichiers nécessaires à la détermination des priorités : il permet de choisir les
OFs à déplacer en priorité en cas de surcharge d’une ressource.
3.1.3
La logique du MRP
Le MRP est un processus itératif qui calcule pour chaque période de l’horizon de planification
et pour chaque produit, ses besoins en composants. Les produits sont traités par niveau de
nomenclature croissant pour que le calcul des besoins s’effectue en cascade. Ainsi, les besoins
en composants générés pour un produit seront traités par la prochaine itération du MRP.
Les besoins générés apparaissent toujours avec une certaine avance correspondant au délai de
fabrication ou de livraison du composant.
Fig. 3.1 – Exemple de nomenclature à 4 niveaux de profondeur
Produit
Lustre
Corps
Système d’éclairage
Support
Ampoule
Commuateur
Plastique
Délai
2
1
2
1
2
2
1
1
Besoin
Lancement
Besoin
Lancement
Besoin
Lancement
Besoin
Lancement
Besoin
Lancement
Besoin
Lancement
Besoin
Lancement
2
3
4
9
36
144
176
36
44
7.2
8.8
7.2
36
36
44
144
192
36
48
8.8
14.1
44
44
48
176
224
44
52
14.1
15.9
5
6
9
9
11
36
48
48
52
192
11
11
12
44
52
52
224
48
52
15.9
6.0
6.0
6.5
7
9
12
12
13
48
8
11
13
13
9
12
52
6.5
Exemple 3.1.1 – Exemple de calcul des besoins en composants d’un lustre
Dans cet exemple, pour livrer 13 lustres en périodes 10, il faut les lancer en production 2
semaines plutôt ce qui génère des besoins en systèmes d’éclairage et en corps de lustre pour la
période 8.
15
10
13
3.2. DÉFAUTS DES SYSTÈMES MRP
Généralement, le calcul de la quantité à mettre en production est toujours supérieure à la
demande car il doit prendre en compte la taille des lots, les taux de rebus, le réapprovisionnement
du stock de sécurité, etc. Ce calcul s’effectue en deux temps :
– calcul des besoins bruts à partir de la demande
– calcul des besoins nets à partir des besoins brutes et des paramètres précédents
3.2
Défauts des systèmes MRP
Le principal défaut de cette méthode de planification qu’est le MRP, est la non prise en
compte des capacités de production pour établir les ordres de fabrication. Ainsi, rien n’assure que,
pour une période donnée, tous les OF planifiés pourront être traités par l’atelier de production. Le
MRP suppose implicitement que le plan directeur de production a été dimensionné correctement
par rapport aux capacités de production.
Cependant, un PDP peut avoir été exagéré, ou à l’inverse, les besoins en ressources n’ont
pas été anticipés. Dans ce cas, les conséquences sont multiples :
– Retards de livraison
– Pénalités financières
– Augmentation des files d’attentes à cause des ressources goulets surchargées
– Augmentation des niveaux de stock
16
Chapitre 4
Planification des capacités de
production
Dans le chapitre précédent, nous avons vu que le principal défaut de l’algorithme de base
du MRP est la non considération des capacités de production lors de la planification des ordres
de fabrication. Néanmoins, la gestion des capacités doit absolument être prise en compte pour
éviter d’obtenir des plans de production irréalisables. C’est donc le rôle de la planification des
capacités de production, qui interviendra à différents moments durant la phase d’élaboration du
plan directeur de production afin d’éviter ces problèmes.
Un problème souvent rencontré au sein des systèmes MRP est l’existance d’un PDP exagéré.
Dans ce cas, le plan de production prévoit plus d’ordres de fabrication que l’atelier ne peut supporter. De plus, ce type de plan occasionne une augmentation des stocks de matières premières
et de composants intermédiaires, une augmentation des files d’attente au niveau des postes de
travail, et du retard dans les livraisons.
Ce chapitre présente donc les différentes techniques qui ont été développées pour s’assurer
que les plans de production sont réalisables.
Fig. 4.1 – Aperçu des différents techniques de gestion de capacité
17
4.1. PLANIFICATION DES BESOINS EN MOYENS DE PRODUCTION
4.1
4.1.1
Planification des besoins en moyens de production
Principe
La première phase de la gestion des capacités de production consiste à planifier les besoins
en moyens de production à long terme (Resource Requirement Planning). Ce processus est
similaire à celui du MRP, excepté qu’au lieu de planifier les besoins en composants, on planifie les
besoins en ressources humaines, matérielles et financières nécessaires à la réalisation du plan de
production (PDP). En revanche, à la différence du MRP, cette planification porte sur l’ensemble
des périodes du PDP et utilise des familles d’articles sans notion de niveaux de nomenclature
(Planification hiérarchisée).
4.1.2
Mise en oeuvre
Dans un premier temps, il faut établir, pour chaque famille d’articles, son profil de ressource
qui définit les besoins en ressources nécessaires à la production d’une unité 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 réduire le nombre de données à traiter, les ressources sont elles
aussi regroupées par centre de charge.
Famille
A
B
C
Usinage
216,77
68,40
40,96
Assemblage
197,28
53,28
38,56
Peinture
180,00
44,40
38,56
Emballage
80.64
23,52
17,28
Tab. 4.1 – Exemple de profils de ressources pour 3 familles d’articles
Dans cet exemple, l’usinage d’une unité de A demande 261,77 heures.
Une fois que le profil de ressource a été établi pour chaque famille d’articles, il ne reste plus
qu’à multiplier, pour chaque période du PDP, les temps obtenus grâce au profil par les quantités
de production prévisionnelles. On obtient ainsi les capacités de production requises par le PDP à
long terme. Généralement, on compare ces résultats avec les capacités disponibles afin de détecter
les ajustements à réaliser. Ces ajustements peuvent nécessiter des investissements lourds dans
de nouvelles unités de production qu’il faut prendre en compte le plus tôt possible.
18
4.2. VALIDATION DU PLAN DIRECTEUR DE PRODUCTION
4.2
Validation du plan directeur de production
Alors que la méthode précédente permet d’établir les besoins en ressources nécessaires à la
réalisation d’un plan de production, celle-ci va permettre de valider l’adéquation entre capacité
disponible et charge du PDP, avant de lancer l’exécution du MRP. La principale différence entre
ces deux méthodes se situe au niveau de détails pris en compte. En effet, cette méthode n’utilisant
pas de planification hiérarchisée, elle calcule la charge engendré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 diffèrent en fonction des données requises
et de leur compléxité.
4.2.1
Approche par facteurs globaux
Cette technique, également appelée CPOF (Capacity Planning Using Overall Factors), est la
plus ancienne. Elle s’appuie sur les informations suivantes pour établir un planning prévisionnel
des charges :
– un plan directeur de production
– le temps total nécessaire à la production de chaque partie d’un produit
– la proportion de temps utilisé par chaque centre de charge de l’atelier
Pour présenter cette approche, nous allons nous baser sur un exemple. Imaginons un plan de
production qui prévoit la production de 15000 lustres (cf. Figure 3.1) par mois et dont la durée
de production moyenne d’un lustre est de 0,22 heure. La première étape consiste à calculer le
nombre d’heures d’atelier requises par mois en multipliant les quantités du PDP par le temps
moyen de production d’un produit. On obtient ainsi la dernière ligne du tableau ci-dessous.
Ensuite, il suffit de diviser ce temps par la proportion historique de temps utilisé par chaque
centre de charge pour obtenir sa charge prévisionnelle. La validation du PDP consiste alors
à vérifier pour chaque période et chaque centre de charge que les capacités disponibles sont
suffisantes.
Centre de charge
Moulage
Usinage
Assemblage
Peinture
Capacité requise
Proportion historique
0,3
0,4
0,1
0,2
Jan
990
1320
330
660
3300
Fev
990
1320
330
660
3300
...
...
...
...
...
...
Déc
990
1320
330
660
3300
Tab. 4.2 – Planification des capacités par l’approche des facteurs globaux
Cette méthode est particulièrement bien adaptée aux ateliers fabriquant des produits d’une
même famille car dans ce cas il est facile d’obtenir les proportions de temps de chaque centre de
charge par rapport à l’atelier.
19
4.2.2
Approche par feuille de capacité
Cette approche correspond à l’approche par profil de ressource présentée dans la partie
précédente. La seule différence est, qu’à ce niveau, on ne traite plus les produits par famille et
par type mais par référence. Par ailleurs, son rôle est axé sur la validation du PDP et non pas
sur les investissements à réaliser.
4.2.3
Approche par profil de ressource
Bien que le nom de cette approche ressemble à celle de la partie précédente, la méthode
utilisée dans celle-ci est beaucoup plus précise et détaillée. Elle se base sur un plan de production
et sur des profils de ressource établis pour chaque produit. Ces profils prennent en compte les
durées opératoires de passage sur chaque ressource.
Un profil se présente sous la forme d’un tableau à 2 dimensions où les colonnes représentent
les périodes de production à partir de la date de mise à disposition de l’article, et les lignes
les ressources nécessaires (cf. Tableau 4.3 et Tableau 4.4). L’intersection d’une ligne et d’une
colonne indique le temps de la ressource nécessaire à la fabrication d’une unité de produits si
elle doit être disponible à la date t.
R1
R2
t-2
a112
a122
t-1
a111
a121
t
a110
a120
Tab. 4.3 – Profil de ressource du produit P1 sur les ressources R1 et R2
R1
R2
t-2
a212
a222
t-1
a211
a221
t
a210
a220
Tab. 4.4 – Profil de ressource du produit P2 sur les ressources R1 et R2
Produit / Période
P1
P2
1
b11
b21
2
b12
b22
3
b13
b23
Tab. 4.5 – Plan de production des produits P1 et P2 sur 3 mois
Dans cet exemple, les produits P1 et P2 ont des durées de fabrication moyennes qui s’étalent
sur trois périodes.
20
À partir du plan de production et des deux profils de ressource précédents, il est alors possible
d’établir la charge prévisionnelle de chaque ressource.
Resource / Période
R1
R2
1
c11
c21
2
c12
c22
3
c13
c23
Tab. 4.6 – Charge prévisionnelle des ressources R1 et R2 sur 3 mois
c11 = a110 b11 + a111 b12 + a112 b13 + a210 b21 + a211 b22 + a212 b23
c21 = a120 b11 + a121 b12 + a122 b13 + a220 b21 + a221 b22 + a222 b23
c12 = a110 b12 + a111 b13 + a210 b22 + a211 b23
c22 = a120 b12 + a121 b13 + a220 b22 + a221 b23
c13 = a110 b13 + a210 b23
c23 = a120 b13 + a220 b23
Le principal intérêt de cette méthode est la prise en compte des durées de production. La
méthode est ainsi plus précise, au prix d’un temps de calcul plus important.
21
4.3. PLANIFICATION DES BESOINS EN CAPACITÉ DE PRODUCTION
4.3
Planification des besoins en capacité de production
La planification des besoins en capacité de production, aussi apppelée CRP (Capacity Requirement Planning) est apparue dans les années 70 avec les systèmes MRP1 . Son rôle est
de déterminer les capacités nécessaires pour exécuter une opération de production. En effet, à
partir des ordres de fabrication fermes et planifiés, le CRP est capable de calculer la charge
occasionnée par ces ordres sur les ressources d’un atelier en simulant leur exécution. On obtient
ainsi pour chaque période de temps de l’horizon de planification, la charge et la capacité de
chaque ressource.
Généralement, le CRP est utilisé conjointement avec le MRP car il permet de vérifier que
tous les ordres de fabrication prévus pourront réellement être traités par la production sans
occasionner de dépassement de capacité. Ainsi, il est souvent le dernier test avant de valider un
plan de production.
Fig. 4.2 – Boucle de contrôle PDP-MRP-CRP
Par rapport aux méthodes décrites précédemment, les résultats du CRP sont beaucoup plus
détaillés puisque cette méthode n’effectue aucun regroupement de ressources.
4.3.1
Calcul de la charge
Le CRP utilise les ordres de fabrication générés par le MRP et les décompose en fonction
des centres de charge qu’ils doivent traverser. Pour chacun des sous-ordres obtenus, il calcule
la charge engendrée sur le poste de travail et l’ajoute à la charge accumulée depuis le début de
la période. Il fait de même avec les OF fermes et/ou planifiés manuellement afin d’obtenir des
informations de charge les plus justes possibles.
La décomposition d’un ordre de fabrication sur les postes de travail s’obtient à partir de la
gamme du produit à fabriquer. C’est pourquoi, l’existance d’un fichier des gammes est devenue
obligatoire à partir des systèmes MRP1.
22
4.3. PLANIFICATION DES BESOINS EN CAPACITÉ DE PRODUCTION
4.3.2
Résultats du CRP
Le CRP produit des diagrammes de charge par poste de travail. Ces diagrammes présentent
pour chaque période la capacité disponible en nombre d’heures et la charge engendrée par la
planificiation. Ces diagrammes permettent d’identifier les surcharges lorsque la charge engendrée
dépasse la capacité disponible et les sous-utilisations dans le cas inverse.
Fig. 4.3 – Exemple de diagramme de charge généré par le CRP
Dans les CRP récents, il est même possible de distinguer la charge ferme et la charge planifiée.
23
Chapitre 5
Techniques de lissage de charge
Jusqu’à présent, les techniques de planification des capacités de production étudiées ne
servaient qu’à vérifier l’adéquation entre les charges prévisionnelles et les capacités disponibles
des ressources. En cas de surcharge, il fallait reprendre le plan directeur de production et
l’adapter jusqu’à ce que les problèmes disparaissent. Cependant, une surchage n’est pas toujours
synonyme de remise à plat du PDP, il existe des méthodes permettant de faire disparaı̂tre
des surcharges temporaires. Généralement, on ne retrouve ces méthodes que dans les systèmes
MRP-II sous l’appelation ajustement charge-capacité.
Les techniques de lissage de charge se classent en deux catégories en fonction l’objet sur
lequel elles agissent. Ainsi, le lissage en parallèle s’applique sur les ressources alors que le lissage
en série porte sur les opérations qui utilisent les ressources surchargées.
5.1
Lissage en parallèle
Le lissage en parallèle est la solution la plus rapide à mettre en oeuvre face à un dépassement
de capacité temporaire car elle consiste à augmenter la capacité des ressources surchargées au
prix d’un coût de production plus élevé.
– Lissage par ajustement des capacités :
Le lissage par ajustement de capacité consiste à augmenter directement la capacité des
ressources surchargées en augmentant leur disponibilité 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 supplémentaires soit augmenter les cadences avec les risques que ça
entraı̂nent.
– Lissage par transfert de capacité :
Aussi appelé lissage en parallèle, il consiste à faire appel à de la sous-traitance pour faire
diminuer les charges de production ou à transférer la ou les opérations qui surchargent un
poste sur des postes équivalents.
24
5.2. LISSAGE EN SÉRIE
5.2
Lissage en série
Si tous les postes d’une même famille de postes interchangeables sont surchargés sur une
période donnée, cela signifie que seul le lissage «en série» (décalage dans le temps de l’opération)
pourra annuler la surcharge. Il existe alors deux possibilités : le décalage à droite et le décalage
à gauche. Le décalage à droite ne peut être envisagé que de manière exceptionnelle, en jouant
sur le stock de sécurité ([LD98]).
La complexité du problème tient au fait que toute modification sur un composant nécessite
le recalcul sur les composants enfants. Il faut donc rappeler le MRP sur le produit concerné et
tous ses composants après tout décalage à gauche. De plus, le report de production implique la
constitution de stock qui a un coût.
Lorsqu’une ressource est surchargée par plusieurs opérations planifiées et que seul le lissage
en série peut être appliqué, il faut choisir l’opération à décaler. Dans ce cas, [VG88] préconise
l’existance d’un fichier définissant des règles de priorité pour déterminer l’opération à décaler.
Ces règles sont généralement calculées sur la base de critères empiriques tels que celui de la
minimisation de la valeur des en-cours constitués lors de décalage. Généralement, on choisit
l’opération dont le coût de déplacement est le plus faible.
5.3
Limitations
Dans le cas du lissage en série, le lissage s’effectue toujours de la période de temps la plus
éloignée vers la plus proche. Cette démarche se justifie par le lissage de la charge par un transfert
des dépassements sur les périodes antérieures.
Si après lissage, la solution du MRP n’est toujours pas réalisable, le plan directeur de
production doit être révisé. Cette remise en cause se traduit par un retard de livraison de
certains articles par rapport à ce qui était initialement prévu. Il faut alors mettre en place des
procédures de traçage (pegging) pour déterminer les commandes à l’origine des surcharges.
25
Chapitre 6
Conclusion de l’état de l’art
Cet état de l’art nous a permis de comprendre le fonctionnement d’un MRP et de soulever son
principal défaut, à savoir la non prise en compte des capacités de production lors de l’élaboration
de la planification. Néanmoins, il existe un certain nombre de méthodes permettant de planifier
les besoins en capacités de production à différents moments dans le système de gestion de
production.
Toutefois, peu de solutions existent au niveau du MRP car la masse de données est généralement
trop importante pour être traitée à ce niveau. C’est pourquoi, la plupart des méthodes agissent
sur les données pré-MRP telles que le plan directeur de production pour vérifier l’adéquation
entre PDP et capacité de production. Ainsi, la méthode RRP permet d’anticiper les besoins en
ressources, et les RCCP permettent de valider le plan directeur.
Cependant, ces méthodes ne peuvent assurer à 100% qu’il n’y aura pas de dépassements de
capacité. Il existe donc des techniques de lissage de charge qui peuvent être appliquées sur les
résultats du MRP pour tenter de faire disparaı̂tre les problèmes de dépassements de capacité
temporaires. Ce type de procédé n’est apparu qu’avec les MRP de type 2.
De nombreux progiciels du marché se réclamant être de type MRP2, ne sont en fait que des
MRP1 auxquels on a ajouté un CRP. Cet élément est obligatoire pour détecter les surcharges
engendrées par la planification du MRP. C’est alors au décideur de mettre en place les actions
nécessaires pour résoudre les problèmes de charge.
26
Troisième partie
Analyse de l’existant
27
Chapitre 7
Étude du MRP existant
Le MRP existant dans Ofbiz a été développé par Thierry Grauss en 2004 dans le cadre de
son projet de fin d’étude [TG04]. Le but de ce projet était de mettre au point l’algorithme
utilisé par le MRP pour calculer les besoins en composants à partir de commandes de vente
d’articles. Cependant, il a été réalisé avant la naissance de projet Néogia, il n’est donc pas
intégré à OfbizNéogia. De plus, les structures de données ont fortement changé, il sera donc
nécessaire de le porter sur la nouvelle architecture. Une telle opération requiert un bon niveau
de connaissance des deux projets d’où l’objet de cette partie.
7.1
Données manipulées par le MRP
Ofbiz n’intè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 données d’entrées
du MRP. Ces enregistrements sont ensuite utilisés pour initialiser la table de travail du MRP,
à savoir la table mouvements de stock planifiés. Cette table permet de suivre l’évolution des
besoins et des arrivées de stock suite à la simulation de lancement d’ordres de fabrication
(OF) ou d’ordres d’achat (OA) par le MRP. Ces simulations sont conservées dans la table
des propositions.
Fig. 7.1 – Données d’entrée/sortie du MRP existant
28
7.2. FONCTIONNALITÉS
7.2
Fonctionnalités
En terme de fonctionnalités, le MRP existant se situe entre le MRP0 et le MRP1 car bien
qu’il ne prenne pas en compte les capacités de production, il utilise la disponibilité des ressources
pour déterminer les délais de d’obtention des composants.
Le MRP réalisé est du type multi-articles multi-niveaux, c’est-à-dire qu’il traite tous les
articles de la table des mouvements planifiés de stocks par niveau de nomenclature, en commençant par le niveau 0. Pour chaque niveau, il applique alors l’algorithme de calcul des besoins
présenté dans l’état de l’art sur chaque article, et passe au niveau suivant. Cet algorithme é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 sécurité.
Par rapport aux MRP du marché à niveau de fonctionnalités équivalent, il lui manque tout
de même une fonction : une notion d’horizon de planification afin de limiter la planification des
besoins en composants à une période de temps de durée raisonnable. Ce point devra être pris
en considération lors du portage du MRP sur la nouvelle architecture d’OfbizNeogia.
7.3
Particularités
Contrairement à ce qu’on trouve dans la littérature ([GP75], [VG88], [LD98]), ce MRP ne
fonctionne pas sur une base périodique mais en temps continu : il prend les mouvements de
stock planifiés les uns à la suite des autres sans les regrouper par période. Cette absence de
découpage temporel de l’horizon de planification s’explique par deux raisons. D’une part, ni
Ofbiz ni OfbizNéogia n’implémentent la gestion d’un plan directeur de production, qui lui est
périodique. D’autre part, il est difficile de trouver une taille de période homogène avec les durées
de fabrication des différents produits.
Une des conditions nécessaires à la réalisation d’un MRP est de disposer d’un fichier de la
durée de fabrication moyenne de chaque article ([VG88]). Or dans le MRP existant, cette durée
est calculée à partir de la date de fabrication, de la gamme opératoire et de la disponibilité des
ressources. Cette approche est plus coûteuse en temps de calcul car il faut recalculer la durée
de fabrication à chaque fois. En revanche, elle est beaucoup plus précise puisqu’elle prend en
compte les périodes de disponibilité des ressources ce qui permet d’utiliser le MRP pour de la
planification à court terme.
29
Chapitre 8
Module de gestion de production
Le module de gestion de production a été le premier module développé par Néréide pour
Ofbiz. Ce module a été ensuite porté sur l’architecture Néogia par Thierry Grauss durant le
stage qui a suivi son PFE. Il comporte actuellement quatres sous-modules :
– gestion des données techniques ;
– gestion d’atelier ;
– gestion de projet ;
– gestion des coûts de production ;
Dans ce chapitre, seuls les deux premiers sous-modules seront détaillés car leurs entités et
leurs fonctionnalités seront utilisées par le MRP et le CRP.
8.1
Gestion des données techniques
Le module de gestion des données techniques est utilisé principalement par le bureau des
méthodes pour définir tous les processus de fabrication (outils, phases d’exécution, gammes, etc)
intervenant dans la production d’un article. Ces données sont ensuite utilisées par le module de
gestion d’atelier pour planifier des ordres de fabrication.
8.1.1
Les ressources
Les ressources d’un atelier sont représentées par l’entité TechDataResource. Une ressource
peut être soit une machine soit une compétence, par exemple : un tour, un régleur. Il est possible
de regrouper plusieurs ressources physiques sous une seule TechDataResource si ces ressources
sont identiques et qu’elles peuvent être interchangées à tout moment. Dans ce cas, l’attribut
resourceQuantity indique le nombre de ressources de ce type.
8.1.2
Le calendrier industriel
L’entité TechDataCalendar représente un calendrier industriel. Un calendrier industriel définit
les périodes de disponibilités et/ou d’indisponibilités d’une ressource. Il est utilisé notamment
pour définir les périodes de maintenance et les périodes de fermeture de l’atelier. Les ressources
30
8.1. GESTION DES DONNÉES TECHNIQUES
Fig. 8.1 – Modélisation d’une ressource d’atelier
d’un atelier ne partagent pas forcément toute le même calendrier industriel.
La mise en oeuvre d’un calendrier industriel se fait de la manière suivante : L’utilisateur
définit une période hebdomadaire typique (CalendarWeek) pour laquelle il indique pour chaque
jours l’heure de début de disponibilité ainsi que la durée. Ensuite, il introduit des exceptions
(CalendarException) dans le calendrier. Une exception est définit par une date, une nouvelle
heure de début de disponibilité et une nouvelle durée.
Fig. 8.2 – Modélisation UML du calendrier industriel
L’implémentation existante du calendrier industriel ne propose qu’une seule méthode add
qui calcule la date de fin d’utilisation d’une ressource à partir de sa durée et de sa date de
début, et inversement. Le CRP nécessitera des méthodes plus complexes pour pouvoir étudier
les disponibilités des ressources sur un horizon de planification.
8.1.3
Les gammes opératoires
Une gamme opératoire définit l’ensemble des opérations nécessaires à la réalisation ou l’assemblage d’un produit. Elle est représentée dans OfbizNéogia par l’entité Routing. Une gamme
est toujours associée à 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
8.1. GESTION DES DONNÉES TECHNIQUES
scrapFactor définit le taux de rebus généralement constaté lors de l’exécution de la gamme, c’està-dire le nombre de pièces non conformes par rapport au nombre de pièces produites. Enfin, la
gamme définit l’ordre de ses opérations via l’attribut SequenceNum de la classe d’association
RoutingComposition.
Fig. 8.3 – Modélisation UML des gammes et des opérations
8.1.4
Les opérations
Les opérations d’une gamme sont modélisées par l’entité Task. Une opération est définie par
sa durée opératoire (estimatedLeadTime), son temps de préparation (estimatedSetupTime), et
par les ressources nécessaires à sa réalisation (TaskResource). Parmi ces ressources, il y en a
obligatoirement une dont l’attribut valueForPlanification est défini à vrai. Cette ressource est
alors utilisée en priorité pour effectuer la planification de l’exécution de l’opération.
8.1.5
Les nomenclatures
Les nomenclatures ne sont pas modélisées dans le module de gestion des données techniques
d’OfbizNéogia car Ofbiz possédait déjà un support complet des nomenclatures dans le module
Product. Avec notamment, la possibilité de gérer des variantes d’un même produit via un objet
appelé Configurator dans le cas de produits avec options.
Ofbiz modélise les arcs d’une nomenclature comme une association entre deux produits composé-composant (entité ProductAssoc). Chaque arc porte le nombre de composants (quantity),
la tâche de la gamme qui requiert le(s) composant(s) (routingWorkEffortId) et une période de
validité.
32
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 réservation
des composants et des demandes de sorties de stocks.
8.2.1
Les ordres de fabrication
Un ordre de fabrication, représenté par l’entité WRun, est une programmation de l’exécution
d’une gamme. Un OF est défini par l’article à produire et sa quantité, par son statut (Planifié,
Ferme, EnCours, ...), par ses dates de réalisations et durées estimées / réelles, ses besoins
en composants et enfin par les opérations qui le composent (TaskFulfilment). Ces opérations
correspondent aux opérations déclarées au niveau de la gamme.
L’entité TaskFulfilment représente la programmation d’une opération. Comme pour un ordre
de fabrication, on retrouve des informations sur les dates de début et de fin estimées/actuelles,
et un statut qui indique l’état de réalisation de l’opération.
Un TaskResourceFulfil représente l’utilisation réelle et/ou planifiée d’une resource pour la
réalisation d’une opération.
Un RunComponent représente un besoin d’un composant particulier. Il doit toujours être
disponible au début de l’opération à laquelle il est lié (TaskFulfilement).
Fig. 8.4 – Modélisation UML des ordres de fabrication
33
8.2. GESTION D’ATELIER
8.2.2
Programmation de la production
La création d’un OF entraı̂ne la programmation de toutes les opérations qui le composent,
la déclaration des mouvements de stocks associés aux sorties de stocks des composants et à la
production du produit associé à l’OF. Ces mouvements de stocks deviendront fermes une fois
l’OF validés.
Dans sa version initiale, la planification d’un OF se fait au plus tôt à partir de sa date de
début estimée (forward scheduling). Ce comportement est incompatible avec le fonctionnement
du MRP qui effectue sa planification à partir des dates de fin. Il faudra donc prendre en compte
ce point lors de l’é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
Quatrième partie
Développements réalisés
35
Chapitre 9
Solution mise en oeuvre
L’objet de cette partie est de présenter la solution mise en oeuvre pour réaliser un MRP à
capacité finie, intégré au module de gestion de production de l’ERP libre OfbizNéogia. Cette
solution se base sur les observations réalisées dans l’état de l’art sur la gestion des capacités de
production, et sur l’étude des fonctionnalités existantes du module de gestion de production.
En outre, la mise en oeuvre d’un tel système étant complexe, une approche descendante a été
privilégiée pour réaliser l’analyse du système. Ainsi, nous verrons dans un premier temps en quoi
consiste un MRP à capacité finie et un algorithme de lissage de charge. Ces premiers éléments
permettront ensuite d’élaborer les spécifications fonctionnelles du système et les différents modules à développer.
9.1
9.1.1
Présentation de la solution
Principe
Après avoir étudié les différentes méthodes concernant la planification des capacité de production et le lissage des charges, il apparaı̂t qu’un MRP à capacité finie est simplement un
MRP traditionnel auquel on associe un CRP et un algorithme de lissage de charge. Dans cette
approche, le MRP génère des propositions de fabrication que le CRP évalue pour déterminer les
ressources qui sont surchargées et celles qui ne le sont pas. On fait ensuite appel à un algorithme
de lissage pour essayer d’étaler les dépassements de charge. Si après lissage, les problèmes de
surcharge perdurent, cela signifie que soit les capacités de production sont insuffisantes, soit le
plan directeur de production est exagéré.
Voici quelques éléments à prendre en compte pour l’élaboration du MRP à capacité finie :
– Découpage temporel : contrairement au MRP existant dans Ofbiz, l’analyse de la charge
des ressources doit s’effectuer par période car la masse de données à ce niveau est trop importante pour pouvoir traiter ce problème en temps continu. Donc le CRP et l’algorithme
de lissage doivent travailler sur une base de temps périodique.
– Lissage à postériori : le lissage de la charge engendrée ne peut s’effectuer qu’après une
première itération du MRP à capacité infinie. En effet, le lissage n’est efficace que s’il est
réalisé sur une solution compléte (prenant en compte toutes les charges).
– Méthode itérative arrière : l’algorithme de lissage peut être amené à avancer une opération
pour étaler la charge. Cette action peut modifier les besoins en composant et donc générer
36
9.1. PRÉSENTATION DE LA SOLUTION
de nouveaux ordres de fabrication qui perturberont les charges sur les périodes précédentes.
C’est pourquoi le lissage doit toujours s’effectuer de la période la plus éloignée vers la plus
proche.
9.1.2
Place du décideur
Dans un système MRP sans mécanisme de lissage, on remet en cause le plan directeur de
production lorsque les propositions du MRP ne sont pas réalisables. En effet, le PDP est supposé
avoir été établi en prenant en compte les capacités de production. Dans ce cas, le décideur doit
intervenir pour déterminer les causes de la surcharge, ajuster le PDP en conséquence et relancer
la planification (cf. Figure 9.1).
Fig. 9.1 – Processus de décision dans un MRP sans lissage
Cependant, il peut aussi décider d’introduire manuellement des ajustements et/ou des transferts de capacité pour faire disparaı̂tre les surcharges. Seulement, ce type d’opération n’est pas
aisé à réaliser à cause notamment de la masse de données. C’est donc à ce moment que l’algorithme de lissage va intervenir pour automatiser certains ajustements. Pour cela, on introduit un
nouveau scénario qui intégre une phase de lissage des charges. Il sera utilisé en premier lieu pour
essayer de résoudre les problèmes de dépassement de capacité. En cas d’échec, il sera possible
de revenir au scénario précédent.
Fig. 9.2 – Processus de décision dans un MRP avec lissage
Les techniques de lissage de charge présentées dans l’état de l’art reposent principalement sur
l’augmentation des capacités de production avec la mise en place d’heures supplémentaires, sur
le transfert de capacité avec de la sous-traitance, et sur l’avancement de certaines opérations.
Les deux premiers points pouvant avoir des conséquences qui dépassent strictement le cadre
37
9.2. ALGORITHME DE LISSAGE EN SÉRIE SIMPLIFIÉ
économique, nous laisserons au décideur le choix d’avoir recours à ces méthodes. En revanche,
l’avancement des opérations qui provoquent les surchages peut facilement être automatisé par
un algorithme de lissage en série. Le seul risque économique concerne l’augmentation du coût
des stocks en raison de la hausse des en-cours.
Ainsi dans ce nouveau scénario, lorsque les propositions du MRP ne sont pas réalisables,
on fait appel au décideur qui peut au choix augmenter les capacités des ressources surchargées,
transférer certaines charges vers de la sous-traitance ou bien ne rien faire. On fait appel ensuite
à l’algorithme de lissage pour tenter de résoudre les problèmes de dépassements de capacité
restants et pour mettre à jour la planification.
9.2
Algorithme de lissage en série simplifié
L’algorithme de lissage présenté ci-dessous a été élaboré à partir d’une description du principe
d’ajustement charge-capacité décrit par Vincent Giard ([VG88]). Il consiste à étudier toutes
les périodes de l’horizon de planification en partant de la dernière période et à reporter les
dépassements de capacité sur les périodes précédentes.
Si un dépassement de capacité est causé par plusieurs opérations, le choix de l’opération à
avancer s’effectue à l’aide d’une fonction de décision paramétrable par l’utilisateur. Idéalement,
cette fonction devrait choisir l’opération qui minimise le coût du décalage.
Le décalage d’une opération consiste à replanifier partiellement l’OF à partir de l’opération
concernée en prenant en compte cette fois les contraintes de capacité existantes. Toutefois, la
replanification peut échouer si aucune programmation respectant les capacités n’est trouvée.
Dans ce cas, l’opération tombe dans la période de rejet (période 0) qui indique que la solution
après lissage n’est toujours pas réalisable.
Après la replanification d’une opération, il est nécessaire de relancer le MRP uniquement
sur l’article traité par l’OF et ses composants pour mettre à jour les besoins en composants.
Cette mise à jour peut générer de nouveaux ordres de fabrication et donc entraı̂ner de nouveaux
dépassements de capacité.
38
9.3. ANALYSE DES BESOINS FONCTIONNELS
9.3
Analyse des besoins fonctionnels
L’élaboration de l’algorithme de lissage était une étape obligatoire pour établir les besoins
fonctionnels car il détermine les fonctionnalités que le MRP et le CRP doivent implémenter.
Ainsi, il doit être capable de récupérer des informations sur les ressources surchargées, de faire
appel à des méthodes de replanification prenant en compte les contraintes de capacité et de
relancer le MRP sur un article donné.
À partir de ces quelques besoins de haut niveau, une analyse descendante a permis d’obtenir
la décomposition fonctionnelle résumée par le diagramme ci-dessous (Figure 9.3). Ce diagramme
montre bien que l’algorithme de lissage repose entièrement sur les fonctionnalités du MRP et
du CRP, et que tous les développements vont porter sur ces deux modules.
Fig. 9.3 – Décomposition fonctionnelle du MRP à capacité finie
9.3.1
MRP
Le MRP existant dans Ofbiz, représenté par le bloc fonctionnel MRP multi-niveau, ne peut
être repris tel quel dans OfbizNeogia. D’une part, les entrées/sorties du MRP doivent maintenant
utilisées les modules de gestion des stocks et de gestion de production d’OfbizNeogia. D’autre
part, l’intégration dans ces modules sera simplifiée si le MRP utilise les technologies de Néogia,
à savoir la modélisation en UML et la génération de code.
Par ailleurs, l’algorithme de lissage nécessite une version modifiée du MRP pour effectuer la
mise à jour des besoins en composant d’un unique article. C’est donc l’occasion de repenser le
MRP pour que les deux versions différentes partagent un maximum de code, et pour faciliter
l’ajout de nouveaux types de MRP tel que les MRP différentiels1 . 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 réapprovisionnement
uniquement pour un article donné sans descendre dans les niveaux de nomenclature. On peut
ensuite implémenter les deux autres MRP à partir de celui-ci.
1
MRP qui prend en compte ses propositions précédentes pour effectuer une replanification partielle.
39
9.3. ANALYSE DES BESOINS FONCTIONNELS
9.3.2
CRP
Le rôle du CRP est de détecter les dépassements de capacité de chacune des ressources de
l’atelier. Pour atteindre cet objectif, le CRP doit conserver pour chacune des ressources, un
planning d’utilisation mis à jour à chaque fois qu’un ordre de fabrication est programmé. Ce
planning, initialisé à partir du calendrier industriel, doit permettre d’obtenir rapidement (c-à-d
sans calcul) la capacité et la charge ferme et/ou planifiée d’une ressource pour une période de
temps donnée.
L’exactitude du CRP repose essentiellement sur la cohérence du planning de chaque ressource. Pour obtenir une planification fiable et cohérente, il centralise donc toutes les méthodes
de planification. Par conséquent, il faudra modifier les méthodes du module de gestion d’atelier
pour qu’elles utilisent celles du CRP.
Enfin, il doit fournir des éléments d’interface graphique pour permettre au décideur de
visualiser les ressources surchargées ainsi que leur diagramme de charge pour déterminer quelles
sont les opérations qui provoquent les dépassement de capacités.
Fig. 9.4 – Exemples d’interfaces graphiques possibles pour le CRP
40
Chapitre 10
Développement du MRP
Le MRP existant ne peut être repris tel quel dans OfbizNéogia car d’une part il n’utilise
pas les nouvelles structures de données introduites par Néogia, et d’autre part il ne dispose
pas des fonctionnalités nécessaires au CRP. En particulier, après avoir replanifier un ordre de
fabrication, il faut être capable de refaire tourner le MRP sur l’article concerné par l’OF pour
mettre à jour le planning de réapprovisionnement des tous ses composants. De plus, Néréide
souhaite finaliser le MRP pour le proposer à ses clients. Il doit donc être parfaitement intégré à
OfbizNéogia tant fonctionnellement que graphiquement.
Le développement du MRP a consisté dans un premier temps à identifier les données en entrée
et en sortie du MRP à partir de l’implémentation existante, et à leur trouver un équivalent dans
OfbizNeogia. Ensuite, l’algorithme général du MRP a été rendu plus modulaire pour pouvoir
être réutilisé dans des variantes du MRP. Enfin, la dernière étape a été d’intégrer le MRP dans
OfbizNéogia sous forme de services et d’interfaces graphiques
10.1
Modélisation du MRP
10.1.1
Les entrées
Dans toute la littérature à propos des MRP, on indique que les données d’entrée d’un MRP
proviennent du plan directeur de production qui contient pour chaque article ses prévisions de
production pour l’horizon de planification. Or dans OfbizNéogia, ce plan directeur de production
n’est pas encore implémenté, on doit donc utiliser une autre source de données : les mouvements
planifiés de stock du module de gestion des stocks d’OfbizNéogia, Facility.
Un mouvement planifié de stock, représenté par l’entité StockEventPlanned, est défini par un
article sur lequel porte le mouvement, une quantité qui indique le sens du mouvement (positive
indiquant une entrée de stock, négative une sortie) et une date de réalisation. Le mouvement
deviendra effectif s’il est transformé en mouvement réalisé avant cette date. Cette distinction
entre mouvements planifiés et réalisé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 donnée à partir du stock réel (QOH) et des mouvements
planifiés.
Mais l’avantage avec Néogia et ses outils de développement est qu’il est possible de modéliser
41
10.1. MODÉLISATION DU MRP
des spécialisations. Ainsi dans le cas des mouvements planifiés de stock, on peut distinguer les
mouvements causés par la mise en production d’un article (RunStockEventPlanned et RunCompoStkEvPlan) de ceux provoqués par une commande clients (OrderStockEventPlanned).
La quantité d’un RunStockEventPlanned est toujours positive car il correspond à la production
d’un ou plusieurs articles résultant d’un OF. Alors que celle d’un RunCompoStkEvPlan est
toujours négative car il correspond à un besoin en composants. Enfin, dans le cas d’un OrderStockEventPlanned, le signe de la quantité dépend du type d’ordre : positif pour un ordre
d’achat et négatif pour un ordre de vente.
Fig. 10.1 – Données d’entrée du MRP
42
10.1.2
Les sorties
Lorsque le niveau de stock d’un article, traité par le MRP, passe en-dessous de son seuil de
sécurité, le MRP va créer un besoin caractérisé par une quantité requise et une date à laquelle
le besoin doit être rempli. Ce besoin se traduit par une proposition (ProposedOrder) qui peut
prendre soit la forme d’un ordre d’achat (OrderItem), pour les matières premières ou les produits
sous-traités, soit la forme d’un ordre de fabrication (WRun) pour les produits manufacturés.
Fig. 10.2 – Données de sortie du MRP
Dans le cas d’une proposition d’ordre d’achat, la création de la proposition entraı̂ne la
création d’une commande d’achat (OrderHeader) avec pour unique produit commandé (OrderItem), l’article de la proposition. Enfin, La commande est créée avec comme date de livraison
la date du besoin. À terme, la création de commandes d’achat pourrait être confiée à un module
achat qui effectuerait des regroupements pour les commandes ayant le même fournisseur et/ou
les mêmes délais de livraison par exemple.
Dans le cas d’une proposition d’ordre de fabrication, un nouvel OF est créé avec pour date
de fin, la date du besoin, pour quantité, la quantité requise et pour la gamme, elle est choisit
automatiquement à partir des données techniques. Cette quantité peut être modifiée en fonction
de la taille des lots et du taux de rebus indiqués par la gamme utilisée par l’OF. Ensuite, ce
dernier est jalonné à partir de sa date de fin en utilisant une méthode de planification arrière.
La création d’un ordre d’achat ou de fabrication entraı̂ne la déclaration des mouvements
de stocks planifiés engendrés par l’exécution potentielle de ces ordres. Bien que ces derniers ne
soient pas validés par le décideur, il est nécessaire de générer les mouvements de stocks pour que
le MRP les prenne en compte lors de sa prochaine exécution ou lors du traitement du niveau de
nomenclature suivant.
43
10.1.3
Structures de contrôle du MRP
Jusqu’à présent les diagrammes UML présentés ne montraient que les données manipulées
par le MRP mais pas son implémentation ni son interface de contrôle.
Fig. 10.3 – Structures de contrôle du MRP
L’élément principal du MRP est l’entité MrpRun qui représente les paramètres d’exécution
du MRP ainsi que les propositions obtenues. Il définit notamment la configuration de l’horizon
de planification avec les attributs planningStartDate et planningLength. Il a aussi pour rôle de
filtrer les mouvements de stocks selon la configuration du MRP.
Afin de pouvoir facilement étendre les fonctionnalités du MRP, le design pattern Stratégie
([DG02]) a été employé pour modéliser les algorithmes du MRP. Ainsi, tout nouvel algorithme
doit implémenter l’interface Mrp qui définit les fonctionnalité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 éviter de bloquer le serveur d’application et tous ses utilisateurs quand le
MRP s’exécute. Pour cela, l’algorithme du MRP est exécuté dans un thread différent de celui de
l’interface. En contre partie, il est nécessaire de mettre en place un mécanisme de synchronisation
pour contrôler l’exécution du MRP. C’est le rôle de la classe MrpController qui implémente le
design pattern Singleton ([DG03a]) pour n’autoriser qu’une seule instance de cette classe.
Outre son rôle de contrôle de l’exécution du MRP, cette classe assure aussi l’interface avec
les utilisateurs du MRP. Ainsi, à travers les méthodes de la classe MrpController, l’utilisateur
peut contrôler l’exécution du MRP, récupérer et modifier son état, et lire les messages d’erreur.
Cette classe joue le rôle de façade ([DG03b]) qui cache la complexité du système sous-jacent.
44
Fig. 10.4 – Diagramme d’état du MRP
45
10.2. ALGORITHMES MIS EN OEUVRE
10.2
Algorithmes mis en oeuvre
10.2.1
Algorithme du MRP mono-article mono-niveau
Pour la mise en oeuvre du CRP et de la méthode de lissage envisagée, deux algorithmes
légèrement différents du MRP vont être nécessaires. Les principales différences entre ces algorithmes se situent au niveau des paramètres d’entré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 même pour ces deux
algorithmes, il donc possible de partager leur partie commune.
Les procédures AvailableToPromise et MinimumStockLevel sont des fonctions du module
de gestion des stocks. La première renvoie une estimation du niveau de stock d’un article donné
pour une date donnée. Cette estimation est établie à partir du niveau de stock courant de l’article
et des mouvements planifiés de stock prévus jusqu’à la date indiquée. La seconde récupère la
taille du stock de sécurité de ce produit, c’est-à-dire le niveau en-dessous duquel le niveau de
stock ne devrait pas passer.
La procédure SelectStockEventPlanned récupère tous les mouvements de stock planifiés
durant l’horizon de planification spécifié pour un article donné. Les mouvements sont renvoyés
triés par date croissante, ainsi la cohérence du niveau de stock de l’article est préservée pendant
les itérations de l’algorithme.
46
10.2.2
Algorithme du MRP mono-article multi-niveaux
Cet algorithme implémente un MRP qui traite uniquement un article et tous ses composants.
Il sera utilisé par l’algorithme de lissage de charge après avoir rejalonné un OF pour réajuster
les besoins en composants et le niveau de stock de l’article produit par l’OF.
Itération
1
2
3
4
5
6
7
ProductSet
{Table}
{Plateau, Pied, Vis}
{Pied, Vis, Plaque}
{Vis, Plaque, Tasseau}
{Plaque, Tasseau}
{Tasseau}
{}
Nomenclature utilisée pour l’exemple
Exemple 10.2.1 – Évolution du ProductSet du MRP mono-article multi-niveaux
47
10.2.3
Algorithme du MRP multi-articles
Cet algorithme correspond au MRP existant dans Ofbiz, c’est-à-dire qu’il génère des propositions d’ordre de fabrication ou d’achat pour maintenir les niveaux de stock à leur minimum
pour tous les articles du catalogue produit sur l’horizon de planification spécifié. Il a été adapté
pour utiliser l’algorithme du MRP mono-article mono-niveau afin de partager le maximum de
code possible entre les différents algorithmes présenté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 considéré. Cette
petite optimisation évite ainsi d’interroger la base de données pour les articles dont on est sûr
qu’ils ne vont pas être traités par le MRP. Cette limitation du nombre d’articles traités est
réalisée par la procédure SelectProductForMrp.
L’algorithme du MRP multi-articles doit se terminer lorsque tous les mouvements de stocks
de l’horizon de planification ont été traités. Or il n’est pas possible d’obtenir cette information
simplement à cause de la masse de données générées. Donc, pour déterminer la fin de l’algorithme,
la donnée d’entrée MaxBomLevelWithNoEvent a été introduite. Elle indique au bout de combien
de niveaux de nomenclature successifs sans mouvement de stock généré on peut considérer le
MRP comme terminé.
La procédure SelectProductForMrp présente un défaut qu’il faudra impérativement corriger
avant d’utiliser le MRP dans un système en production : elle ne vérifie pas, si le réapprovisionnement
de l’article doit se faire via un MRP ou via une méthode de gestion scientifique des stocks. Il
existe bien un champ RequirementProductEnumId prévu à cet effet dans l’entité Product mais
pour l’instant aucune valeur n’existe pour cette énumération.
48
10.3. INTÉGRATION DANS OFBIZNÉOGIA
10.3
Intégration dans OfbizNéogia
L’intégration du MRP dans OfbizNeogia consiste : d’une part, à déclarer les services du
MRP pour qu’ils puissent être appelés par tous les moyens mis à disposition par le ServiceEngine d’Ofbiz, et d’autre part à mettre au point les interfaces graphiques nécessaires pour que
l’utilisateur puisse se servir du MRP
10.3.1
Services du MRP
Pour que l’utilisateur puisse contrôler le MRP depuis une interface graphique, il faut rendre
les fonctionnalités de classe MrpController disponibles sous la forme de services. Un service
permet d’exécuter une procédure indépendamment de son langage de programmation, de sa
localisation. Il est possible de passer et de récupérer des paramètres à un service, de ne le rendre
exécutable que par un utilisateur authentifié, de l’exécuter dans une transaction de base de
donné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"
<description>Reset the Manufacturing Requirements Planning process</description>
</service>
<service name="startMrp" engine="java" invoke="startMrp"
<description>Start Manufacturing Requirements Planning computation</description>
</service>
<service name="runMrp" engine="java" invoke="runMrp" use-transaction="false"
<description>Run Manufacturing Requirements Planning computation</description>
</service>
<service name="cancelMrp" engine="java" invoke="cancelMrp"
<description>Cancel Manufacturing Requirements Planning computation</description>
</service>

Fig. 10.5 – Extrait du fichier servicedef.xml du module gestion de production
On remarque que pour le service runMrp, qui correspond à l’exécution du MRP, l’utilisation
des transactions est désactivée. En effet, l’utilisation d’une transaction assure l’isolation des
49
requêtes vers la base de données, en contre-partie des mécanismes d’accès exclusif à certaines
tables peuvent empêcher des utilisateurs d’accéder à ces tables. Or le MRP est un processus
long et il faut éviter ce type de cas de figure. C’est pourquoi, les transactions sont désactivées
au niveau du service et gérées manuellement au niveau du code du MRP.
10.3.2
Interfaces graphiques du MRP
Le MRP propose trois types d’interfaces graphiques selon les fonctionnalités auxquelles
l’utilisateur souhaite accèder. La première est une interface principale qui permet de configurer
le MRP, de l’exécuter, puis de lister les ordres de fabrication ou d’achat proposés. Pour l’instant
cette interface ne dispose pas d’un mécanisme permettant de mettre à jour les résultats du MRP
au fur et à mesure de son avancement. L’utilisateur est alors obligé 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 même machine, et qu’un rechargement automatique de la page peut être coûteux
sur le serveur et peut ralentir le MRP (accès à la base de données, pages dynamiques, ...).
Fig. 10.6 – Interface principale du MRP
Contrairement à la première interface, la seconde est une page de gestion des MrpRun qui a
été entièrement générée par les générateurs de code de Néogia à partir du diagramme de classes
du MRP. Elle permet de lister les MrpRun, de les supprimer et d’en créer de nouveaux.
Fig. 10.7 – Interface de gestion des MrpRun
Le but de la dernière interface développée est de pallier les défauts de l’interface principale,
à savoir l’impossibilité de suivre l’avancement du MRP de manière automatique à cause de la
charge engendrée sur le serveur. La solution à ce problème est l’utilisation d’une technologie permettant de faire dialoguer un serveur web et un navigateur de manière asynchrone par l’é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’intérêt d’un système AJAX
est que le temps de traitement sur le serveur d’une requête est beaucoup plus rapide que la
création et l’envoi d’une page web complète. Le serveur d’applications se retrouve moins chargé
permettant ainsi la mise en place de mécanismes de mise à jour automatique.
50
Cette interface permet de charger une configuration (MrpRun), d’exécuter le MRP, de suivre
en «temps-réel1 » l’état du MRP (niveau de nomenclature courant, article courant, pourcentages
d’avancement, messages d’erreur, ...), d’annuler son exécution ou bien de la recommencer. À
terme, cette interface sera présentée automatiquement à l’utilisateur lors du lancement du MRP
depuis l’interface principale.
Fig. 10.8 – Interface de contrôle du MRP
Ci-dessous, un exemple de message XML échangé entre le serveur d’applications et le navigateur du client pour récupérer l’é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. 10.9 – Sérialisation d’un MrpState
1
toutes les secondes
51
Chapitre 11
Développement du CRP
La mise en oeuvre d’un CRP nécessite des structures de données adaptées à la planification
des capacités de production et à la planification des charges engendrées par le MRP sur l’outil
de production. D’une part, le CRP s’exécute sur un temps discret décomposé en périodes, et
pour chacune d’entre-elles, il faut être capable de déterminer la capacité 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 cohérence et la justesse de ces données.
Le développement du CRP s’articule autour de la mise au point des structures de données
et de la reprise de tous les algorithmes de planification de ressources d’OfbizNéogia pour qu’ils
utilisent ces structures de données. Enfin, le dernier élément important dans le développement
du CRP est la réalisation de l’algorithme de planification à capacité finie qui sera à la base de
l’algorithme de lissage par la suite.
52
11.1. STRUCTURES DE DONNÉES DU CRP
11.1
Structures de données du CRP
Le CRP sera implicitement utilisé par le MRP lorsque ce dernier créera des ordres de
fabrication. Les structures de données ne doivent donc pas pénaliser l’exécution du MRP. Ce
type de contrainte conduit généralement à une complexité spatiale plus importante ce qui peut
impacter sur les performances de l’ensemble à cause de l’accès à la base de données. Il faut
donc développer des structures avec un bon compromis entre temps de recherche et temps de
chargement.
11.1.1
Gestion de plannings
Lors de l’élaboration de la solution, il a été noté que le CRP devait fonctionner sur une base
de temps périodique. Il faut, en particulier, être capable de récupérer la capacité et la charge
d’une ressource pour une période donnée. En outre, pour éviter d’avoir à recalculer des données
périodiques constantes1 telle que la capacité d’une ressource, ces données doivent être calculées
une fois puis conservées dans une structure de données adaptée que nous appelerons Planning.
Or ce type de structure n’existe pas dans OfbizNeogia, il a donc fallut les développer. Dans
ce type de situation, il faut en profiter pour modéliser une structure qui puisse être réutilisée
par d’autres modules du progiciel. Ainsi, la modélisation réalisée pour conserver des données
périodiques (cf. Figure 11.1) a pu être réutilisée par l’équipe chargée de la modélisation des
prévisions de vente et du plan directeur de production.
Un planning est défini par une périodicité et par un ensemble de périodes de temps successives
pas nécessairement de tailles fixes (PlanningPeriod). Par exemple, dans un planning avec une
périodicité mensuelle, on peut trouver des périodes de 29, 30 et 31 jours. Enfin, l’attribut
referenceDate définit la date de début de la période 0.
Fig. 11.1 – Modélisation UML de la notion de planning
Le fait d’avoir modélisé les périodes d’un planning par une interface permet d’utiliser le
design pattern Factory du côté du planning. Ainsi les développeurs souhaitant utiliser cette
modélisation sont libres de choisir les données périodiques à conserver, du moment qu’il respecte
la spécification de l’interface. Un exemple d’utilisation de cette méthode est la modélisation du
planning d’une ressource dans la partie suivante.
1
qui ne changent pas au cours d’une période
53
Les méthodes permettant de calculer la durée d’une période n’apparaissent pas sur le diagramme de classes ci-dessus. Néanmoins, elles sont centralisées au niveau de l’entité PlanningPeriodicity pour faciliter la réutilisation de cette entité dans d’autres modules.
La gestion des périodes d’un planning n’est pas forcément simple quand les périodes sont de
tailles différentes. Pour simplifier cette tâche, deux outils ont été introduits : PeriodIterator
et PlanningPeriodIterator. Le premier permet de manipuler des périodes de temps de durée
variable. Le second hérite du premier et est lié à un planning. Il permet d’énumérer les périodes
d’un planning sans avoir besoin de lire la base de données.
Fig. 11.2 – Modélisation UML de la notion de planning
54
11.1.2
Modélisation des capacités d’une ressource
Maintenant qu’une structure de données adaptée à la gestion de données périodiques est disponible, elle va être spécialisée pour la modélisation des capacités d’une ressource. Ainsi l’entité
ResourcePlanning hérite de Planning pour gérer des périodes de type ResourcePlanningPeriod.
Une période est définie par sa date de début et sa durée. Les attributs StartOffset et availability
indiquent respectivement le début et la durée de disponibilité de la ressource dans la période
considérée. Enfin les attributs ressourceQuantity et maxResourceQty donnent le nombre de
d’unités de ressource disponible ainsi que la quantité maximum qu’il est possible d’utiliser pour
la période.
Fig. 11.3 – Modélisation UML des capacités des ressources
Fig. 11.4 – Schéma simplifié d’un ResourcePlanning
Calcul de la capacité d’une ressource pour une période :
capacity = availability ∗ resourceQuantity
Un planning étant potentiellement infini, ses périodes sont créées à la demande lorsque
l’application tente d’accèder à l’une d’entre-elles. Lors de leur initialisation, les capacités sont
55
fixées à partir du calendrier industriel de la ressource. Le décideur pourra ensuite les modifier
pour intégrer des heures supplémentaires, par exemple. Une difficulté qui est apparue lors de
l’élaboration du CRP, est que les périodes d’un planning ne correspondent pas forcément à celle
du calendrier industriel. Il faut alors effectuer des estimations qui nuisent un peu à la précision
de l’ensemble. Ainsi la date de début de disponibilité d’une ressource est calculée de la manière
suivante :
(duration − availability)
startOf f set =
2
Comme indiquée en introduction, le gain de temps gagné sur le calcul des capacités d’une
ressource a des répercutions sur la quantité de données à extraire depuis la base de données.
Pour pallier ce problème, un mécanisme de caches a été mis en place pour conserver les plannings
et leurs périodes en mémoire le temps d’un traitement important tel que l’exécution du MRP
ou le lissage des charges. Ces caches peuvent être paramétrés pour fonctionner dans un mode
LRU (Last Recent Use). Cependant, pour conserver la cohérence des données entre cache et
base de données, les modifications de plannings doivent se faire exclusivement via le CRP. C’est
pourquoi toutes les opérations de planification sont centralisées dans ce module.
11.1.3
Modélisation des charges d’une resources
Le but de cette modélisation est d’être capable à tout moment, de calculer simplement la
charge d’une ressource pour une période donnée. De plus, pour l’algorithme de lissage, il faut être
capable de récupérer les opérations qui utilisent cette ressource et de distinguer la charge ferme
de la charge planifiée. Pour atteindre ces objectifs, il suffit de lier l’utilisation des ressources
(TaskResourceFulfil) aux RessourcePlanningPeriod correspondant.
Fig. 11.5 – Modélisation UML des charges des ressources
À l’heure actuelle, l’entité ResourcePlanningPeriod ne contient aucun champs concernant
la charge de la période car il est facile de l’obtenir en sommant le champs duration de chaque
ResourceUsage associé à la période. S’il s’avère à l’usage que ce calcul est finalement coûteux, il
est prévu d’ajouter les champs plannedLoad, closedLoad et totalLoad à l’entité ResourcePlanningPeriod. Ces champs devront être mis à jour après chaque planification.
56
11.2. ALGORITHMES DE PLANIFICATION
11.2
Algorithmes de planification
Cette partie présente les différents algorithmes de planification mis en oeuvre dans le cadre
du CRP. Ces algorithmes se basent sur les structures de données décrites précédemment, et
sur celles du module de gestion d’atelier. En effet, ils portent sur la planification des ordres de
fabrication et de leurs opérations, ainsi que sur la planification de l’utilisation des ressources.
Afin de rester strictement dans le cadre du couple MRP-CRP, les algorithmes présentés
ne fonctionnent qu’en planification arrière (planification à partir des dates de fin) bien qu’ils
intègrent en réalité aussi la planification avant. Par contre, ils intègrent la prise en compte des
capacités de production.
11.2.1
Algorithme de planification d’un OF
L’algorithme de planification d’un ordre de fabrication est très simple puisque ce n’est pas
à ce niveau que l’on traite la planification multi-ressources ou que l’on prend en compte les
capacités. Ces problèmes seront traités dans les parties suivantes, à savoir la planification d’une
opé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 à
partir de sa date de fin estimée. Pour obtenir ce résultat, il suffit simplement de planifier chacune
de ses opérations en les prenant dans l’ordre inverse de leur réalisation. Ainsi, la date de début
calculée d’une opération devient la date de fin estimée de l’opération précédente de l’OF.
La planification d’un OF entraı̂ne la mise à jour de ses besoins en composants, et par la
même occastion, la mise à jour des mouvements de stock planifiés qu’il génère. Ces mises à jour
s’effectue automatiquement via un mécanisme d’évènements interne à d’Ofbiz appelé SECA
qui déclencle l’appel des services de mise à jour. C’est pourquoi ils n’apparaissent pas dans
l’algorithme.
Le rôle de la donné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 être la date de début de l’horizon
de planification du MRP. Nous verrons son utilité dans la section suivante.
57
11.2.2
Algorithme de planification d’une opération
La principale difficulté dans la mise en oeuvre de la planification d’une opération est le
fait qu’elle puisse nécessiter plusieurs ressources. Dans ce cas, toutes les ressources doivent être
disponibles pendant l’opération. Par ailleurs, ces ressources peuvent ne pas avoir le même type
de planning ce qui rend la recherche de périodes de disponibilité communes encore plus délicate.
Pour comprendre la difficulté de l’algorithme à mettre en oeuvre, nous allons nous basé sur
un exemple de planification d’une opération nécessitant trois ressources.
Fig. 11.6 – Exemple de planification d’une opération
Dans l’exemple ci-dessus (Figure 11.6), on commence par planifier la ressource dont l’indicateur valueForPlanification est à 1 conformément aux spécifications du module de gestion
d’atelier. L’utilisation de cette ressource détermine ainsi la position de l’opération dans le temps.
Ensuite, il ne reste plus qu’à planifier l’utilisation des ressources restantes dans l’intervalle de
temps définit par l’utilisation de la premiè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 posée par
cet intervalle. Dans ce cas, on annule les planifications réalisées et on recommence la planification
de la première ressource à partir de la période précédente de son planning (Figure 11.7).
Fig. 11.7 – Exemple de planification d’une opération
Pour éviter, un temps de recherche infini lorsque les plannings des ressources sont incompatibles ou lorsqu’en mode planification à capacité finie les ressources sont surchargées, une date
limite a été introduite. Elle définit la date de début minimale de l’utilisation de toute ressource.
58
59
11.2.3
Algorithme de planification de l’utilisation d’une ressource
L’algorithme de planification de l’utilisation d’une ressource est important car c’est à ce
niveau que les structures de données du CRP vont être utilisées pour prendre en compte la
capacité et la charge d’une ressource. Il consiste à rechercher dans le planning d’une ressource
un emplacement compatible avec l’utilisation prévue de la ressource. On entend par compatible,
un emplacement situé dans l’espace de recherche, qui remplit les besoins en capacité et quantité de ressource. L’espace de recherche est définit par l’intervalle [BoundDate, DueDate]. La
planification à capacité finie est activée lorsque finiteCapacity est à 1.
L’élément important de cet algorithme est l’objet Period qui correspond à l’entité ResourcePlanningPeriod. C’est à partir de cet objet que l’on récupére la capacité disponible d’une
ressource et que l’on met à jour sa charge.
60
11.3. CONSÉQUENCES DE LA PLANIFICATION À CAPACITÉ FINIE
11.3
Conséquences de la planification à capacité finie
Dans cette partie, on ne s’intéresse qu’à la planification des ressources car c’est le seul endroit
où les capacités de production vont intervenir.
Une caractéristique principale de cette implémentation de la planification à capacité finie
est l’allongement du temps nécessaire à la réalisation d’un ordre de fabrication. D’une part, à
cause de la prise en compte des capacités de production mais aussi parce qu’on ne doit plus
fixer des dates de début et de fin d’utilisation d’une ressource. C’est le rôle d’un algorithme
d’ordonnancement et pas celui du CRP, qui doit uniquement vérifier que les capacités sont
disponibles pour une période donnée. Ainsi, ne sachant pas quel sera l’ordonnancement utilisé,
les dates de début et de fin d’utilisation d’une ressource sont bornées par les dates de début et
de fin des périodes utilisées.
Fig. 11.8 – Exemple de planification à capacité finie
Allongement du temps nécessaire à la réalisation d’un ordre de fabrication car des opérations
ne peuvent plus utiliser une même ressource pendant une même période. En effet, lorsque l’on
planifie l’utilisation d’une ressource on sait pendant quelles périodes elle va être utilisée mais pas
ses dates de début et de fin. Donc pour éviter tout recouvrement, l’algorithme de planification
à capacité finie s’assure qu’il y a toujours une période d’écart pour l’utilisation successive d’une
ressource par un même OF.
Fig. 11.9 – Allongement du temps nécessaires à la réalisation d’un OF
Enfin, allongement du temps nécessaire à la réalisation d’un ordre de fabrication car si la
date de fin d’utilisation d’une ressource tombe au milieu d’une période on est obligé de l’avancer
à la période précédente. En effet, ne sachant pas quel sera l’ordonnancement utilisé, il n’est pas
possible d’assurer que l’utilisation de la ressource sera bien terminée à la date de fin indiquée.
61
11.4. INTÉGRATION AVEC LE MODULE DE GESTION D’ATELIER
Fig. 11.10 – Allongement du temps nécessaires à la réalisation d’un OF
Le principal défaut de la méthode de planification à capacité finie utilisée est qu’elle n’est
pas toujours fiable. Ce n’est pas parce que la capacité nécessaire est disponible que la solution
est réalisable car l’algorithme de planification ne prend pas en compte la quantité de ressource
disponible. Ainsi, si 5 ressources identiques sont disponibles pendant 24h et que deux opérations
nécessitent respectivement 4 ressources pendant 24h et 3 ressources pendant 5h ; la solution
n’est pas réalisable car bien que la charge soit inférieure à la capacité, le nombre de ressources
nécessaires à chaque instant n’est pas suffisant.
11.4
Intégration avec le module de gestion d’atelier
Lors de l’é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
intermédiaire. C’est pourquoi, les algorithmes de planification d’OFs et d’opérations existants
ont été entièrement repris pour intégrer l’utilisation des plannings.
Cependant, les algorithmes de planification du module de gestion d’atelier fonctionnent
en planification avant (forward scheduling2 ) contrairement au MRP qui utilise la planification
arrière (backward scheduling3 ). Ainsi, l’intégration du CRP dans ce module a dû être réalisée
en conservant le mode de planification initial. Par conséquent, tous les algorithmes présentés
précedemment intègrent la notion de sens de planification. De ce fait, la planification manuelle
d’un OF bénéficie du CRP et de ses mécanismes de détection de surcharge.
2
3
planification à partir des dates de début
planification à partir des dates de fin
62
Cinquième partie
Bilan
63
Chapitre 12
Bilan du projet
12.1
État d’avancement
Les modules prévus dans la décomposition fonctionnelle présentée dans le chapitre «Solution
mise en oeuvre», n’ont pas encore été tous implémentés en raison des temps de développement
requis pour une application de cette ampleur et de certains problèmes rencontrés. Ainsi, l’état
d’avancement du projet est estimé à 70% réalisé.
En particulier, l’algorithme de lissage des charges n’a pu être terminé à temps à cause
de problèmes rencontrés tardivement au niveau la planification multi-ressources à capacité
finie et au niveau de la replanification des besoins en composants. En revanche, le reste des
fonctionnalités annoncées sont fonctionnelles. Ainsi, OfbizNéogia dispose d’un MRP couplé à
CRP ce qui le classe désormais dans la catégorie des MRP-1.
12.2
Problèmes rencontrés
12.2.1
Problèmes fonctionnels
Problème lié à la replanification des besoins
L’algorithme d’ajustement charge-capacité prévu, peut être amené à décaler des OF afin
de faire diminuer les charges pesant sur les ressources. Or, ces décalages peuvent avoir des
conséquences sur les niveaux de stock qui n’avaient pas été prévues lors de l’élaboration de
l’algorithme. En effet, si l’opération que l’algorithme souhaite décaler nécessitait des besoins
en composants, et que ces besoins ont généré des propositions d’OF, alors le décalage va bien
décaler les besoins en composant mais ne va pas annuler les OF proposés. On risque ensuite
d’avoir une hause des niveaux de stock et une utilisation inutile des ressources de l’atelier.
Ces conséquences ne remettent pas en cause l’algorithme de lissage mais il faudra mettre en
place un mécanisme pour détecter les propositions inutiles lors de l’appel au MRP chargé de
refaire la planification des besoins en composants après le décalage d’une opération. À l’heure
actuelle, deux solutions sont envisagées pour résoudre ce problème :
– utiliser un MRP différentiel qui ajusterait les propostions existantes ;
64
12.2. PROBLÈMES RENCONTRÉS
– développer un mécanisme de «pegging ([GP75])» permettant de retrouver l’origine d’une
proposition et de l’ajuster si le besoin n’existe plus.
Probléme lié à la planification multi-ressources à capacité finie
L’algorithme de planification d’une opération, lorsqu’il est utilisé en planification à capacité
finie, présente un risque de ne jamais trouver de solution du fait des décalages de temps introduits
par la planification à capacité finie (cf. Section 11.3). Pour éviter un bouclage infinie, des
dates limites de planification ont été introduites cependant cette amélioration ne résoud pas
le problème.
Il existe pourant une solution partielle à ce problème, qui consisterait à diminuer la durée
de l’opération pour augmenter les chances de trouver une configuration valide. Le seule moyen
disponible pour faire baisser la durée d’une opération est de diminuer la quantité à produire
en avançant une partie de la production. Cette solution obligerait l’algorithme de lissage à ne
plus considérer uniquement le décalage d’une opération mais aussi le décalage des quantités à
produire. À ce stade, il serait peut-être plus simple de revoir le plan directeur de production
plutôt que du perdre du temps à trouver une configuration valide.
12.2.2
Problèmes techniques
Le principal problème technique rencontré concerne la concurrence de transactions avec la
base de données lors de l’exécution du MRP. Par défaut, un service Ofbiz s’exécute dans une
transaction qui assure l’isolation par rapport à des requêtes s’exécutant sur la base de données.
Or le MRP é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’accéder à l’entité MrpRun.
12.2.3
Temps de développement
Les temps de dé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 débogueur avec Ofbiz. Il faut alors utiliser des logs pour tracer le contenu
des variables et l’exécution des algorithmes. De même, la mise en place de procédures de tests
est rendue délicate en raison de l’omniprésence de la base de données et du temps de lancement
de l’ERP qui oscille entre 30 et 90 secondes avant d’obtenir la main sur le système.
Pour ce projet, j’au eu la chance de pouvoir travailler directement sur le dépot CVS contenant
les sources d’OfbizNéogia. J’avais ainsi accès à un système de suivi des modifications du projet
ce qui me permettait de suivre l’évolution des différents modules nécessaires au MRP. En contrepartie, il fallait éviter de «casser» le projet en «commitant» des développements ne compilant
pas. Il était donc nécessaire de passer un certain temps à vérifier que les modifications appportées
au projet n’allaient pas empêcher les contributeurs du projet de travailler.
65
12.3. AMÉLIORATIONS POSSIBLES
12.3
Améliorations possibles
L’infrastructure du MRP et du CRP mise en place fournit une base stable pour de futurs
développements. Cependant, le temps de mise en oeuvre de cette infrastructure a consommé du
temps de développement initialement prévu pour d’autres aspects du projet.
Actuellement, le CRP ne dispose d’aucune interface permettant au décideur de visualiser les
dépassements de capacité car les scénarios ne sont pas encore complétement définis. Il faudrait,
en particulier, qu’il puisse faire les ajustements de capacité des ressources directement depuis
l’interface du CRP avant de laisser la main à l’algorithme de lissage.
Un point important qui n’a pas été réalisé faute de temps, est la réalisation d’un jeu de
données conséquent pour tester les performances du couple MRP-CRP. Jusqu’à présent, les
développements ont porté sur la réalisation d’un système fonctionnel sans prise en compte des
performances. La seconde phase des développements consistera donc à améliorer le système pour
atteindre des performances correctes pour un système MRP-1. Une possibilité est de développer
un générateur de nomenclatures, de gammes et mouvements de stocks planifiés pour tester le
système aux limites.
66
Chapitre 13
Conclusion
Bien que ce projet ne soit pas complétement terminé, les éléments développés sont fonctionnels et sont d’ores et déjà présentés aux futurs clients de Néréide lors des démonstrations du
progiciel. De même, certaines modélisations commencent à être réutilisées dans d’autres parties
du progiciel, notamment la gestion de planning.
Ce projet est le plus important que j’ai été amené à développer jusqu’à présent. Il m’a
permis de découvrir la gestion de production, la mise en oeuvre d’un MRP et les différentes
problématiques liées à 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 américains d’Ofbiz.
Bien qu’ayant déjà travaillé sur OfbizNéogia au cours d’un stage précédent le PFE, ma plus
grande difficulté a été d’avoir une vision globale du projet durant les phases de conception. Concevoir un système le plus ouvert possible pour permettre facilement l’ajout et/ou la réutilisation de
fonctionnalités n’est pas une tâche simple quand tous les éléments ne sont pas clairement définis.
D’ou un temps non négligeable passé à comprendre le fonctionnement du couple MRP-CRP. De
plus, le développpement d’un système ERP est complétement différent du développement d’une
application isolée du fait que plusieurs utilisateurs peuvent être connectés au système à tout
instant, que les ressources doivent être partagées, que tout passe par une base de données, etc.
Enfin, ce projet ne s’arrête pas là puisqu’il fait l’objet d’un stage de fin d’étude chez Néréide.
Ce stage devrait me permettre de terminer les fonctionnalités manquantes pour obtenir un
MRP-2, à savoir la mise en oeuvre de l’algorithme d’ajustement charge-capacité.
67
Sixième partie
Annexes
68
Annexe A
Modélisation des données techniques
dans OfbizNeogia
69
Annexe B
Modélisation des ordre de
fabrication dans OfbizNeogia
70
Annexe C
Modélisation du MRP réalisé
71
Annexe D
Modélisation des charges/capacités
des ressources
72
Glossaire
A
APS ( Advanced Planning Systems )
Logiciels censés apporter de nouvelles fonctions comme une replanification rapide, une
planification sous contrainte, un chargement à capacité finie, un algorithme de lissage de
charge. Voir aussi «MPS».
C
CMMS ( Computerized Maintenance Management system )
Gestion de Maintenance Assistée par Ordinateur.
CMS ( Content Management Systeme )
Également nommé progiciel de gestion du contenu (PGC), un système de gestion de
contenu permet de gérer le contenu des sites web qu’il administre sans avoir besoin d’écrire
de code HTML ni d’utiliser d’outils de développement.
CRM ( Customer Relationship Management )
Concept préconisant la centralisation au sein d’une base de données de toutes les interactions entre une entreprise et ses clients, afin de mettre en commun et maximiser la
connaissance d’un client donné.
D
Design Pattern ( Modèle de conception )
Dans le monde de l’orienté-objet, les design patterns se présentent comme un catalogue de
méthodes de résolution de problèmes récurrents.
E
ERP ( Enterprise Resource Planning )
M
MDA ( Model Driven Architecture )
Model-Driven Architecture (MDA) est une architecture proposée par l’OMG dont l’objectif
est de rendre le métier de l’entreprise indépendant du middleware d’accès.
73
GLOSSAIRE
MPS ( Master Production Schedule )
Un MPS est un ...
MRP ( Material Requirements Planning )
Un MRP est un système qui à partir d’un plan directeur de production établit la liste
des besoins en composants. Un besoin étant définit par une quantité et une date de
disponibilité. Voir aussi «MPS».
O
OPT ( Optimized Production Technology )
S
SCM ( Supply Chain Management )
Technique de gestion consistant à s’occuper de toute la chaı̂ne logistique, des fournisseurs
aux clients en passant par la production. Le SCM passe par la mise en place de logiciels
sachant gérer tous les flux physiques d’une entreprise.
74
Bibliographie
[CH05]
La théorie des contraintes, Christian HOHMANN, <http://membres.lycos.
fr/hconline/toc/toc3c.htm>.
[DF91]
Production and Inventory Management, Donald W. Fogarty, John H. Blacksc 1991 South-Western Publishing Co.,
tone, et Thomas R. Hoffman, Copyright 0-539-07461-2, South-Western Publishing Co..
[DG02]
Strategy for success, David Geary, <http://www.javaworld.com/javaworld/
jw-04-2002/jw-0426-designpatterns.html>. 10.1.3
[DG03a]
Simply Singleton, David Geary, <http://www.javaworld.com/javaworld/
jw-04-2003/jw-0425-designpatterns_p.html>. 10.1.3
[DG03b]
Façade clears complexity, David Geary, <http://www.javaworld.com/
javaworld/jw-05-2003/jw-0530-designpatterns.html>. 10.1.3
[GP75]
c 1996
Orlicky’s Material Requirements Planning, George W. Plossl, Copyright MCGraw-Hill, Inc., 0-07-050459-8, MCGraw-Hill, Inc.. 7.3, 12.2.1
[JF03]
GPAO.NET - Le centre des ressources de la gestion de production, Jerome
Framery, <http://perso.wanadoo.fr/gpao.net/>.
[LD98]
La gestion industrielle, Lionel Dupont, 2866017080, Hermes Science Publications. 3.1.1, 5.2, 7.3
[LS91]
The Data Model Resource Book : A Library of Universal Data Models by
c 1991 Wiley, 0-471-35348-5, Wiley.
Industry Types, Len Silverston, Copyright [NA04]
The Neogia Project, Olivier Heintz et Yannick Thebault, <http://www.
neogia.org/>.
[OZ01]
The Open For Business Project, David E. Jones et Andy Zeneski, <http:
//www.ofbiz.org/>.
[SG97]
Le monde industriel , SupGedem.net, <http://gpr.insa-lyon.fr/supgedem/
Home/nonjava.htm>.
[TG04]
Un module MRP pour un ERP libre Open For Business, Thierry Grauss,
c 2004 Thierry Grauss. 7
Copyright [VG88]
Gestion de la production 2e édition, Vincent Giard. 3, 5.2, 7.3, 9.2
75
Résumé
L’objectif de ce projet était de porter le MRP existant d’Ofbiz vers OfbizNeogia et de lui
ajouter la prise en compte des capacités de production pour établir sa planification. La solution
consiste, dans un premier temps, à développer un CRP (Capacity Requirement Planning)
qui permet de détecter les ressources surchargées. Puis, il faut implémenter un algorithme
d’ajustement charge-capacité dont le rôle est de lisser la charge. En plus du CRP, il a fallut
redévelopper tous les algorithmes de planification pour qu’ils utilisent les structures de données
du CRP.
Mots-clés
Ofbiz, Neogia, MRP, CRP, ajustement charge-capacité
Abstract
The aim of this project was to port existing MRP from Ofbiz to OfbizNéogia and to add
it the ability to take in account production capacities to establish its planning. In a first time,
the solution was to develop a CRP (Capacity Requirement Planning) which allows detection of
overload resources. Then, it’s necessary to implement a load-capacity adjustment algorithm to
smooth the load. Due to OfbizNeogia’s particularities, MRP and CRP are deeply coupled. So in
addtion of the CRP, it had to reimplement all planification algorithms in order they use CRP
data structures.
Keyword
Ofbiz, Neogia, MRP, CRP, load-capacity adjustment
Étudiant :
GORON Peter
EPU-DI 3e année
Année 2004-2005
Encadrants :
SOUKHAL Ameur
HEINTZ Olivier

Rapport de projet de fin d`étude Développement d`un MRP `a

Transcription

Documents pareils

LOCATIONS - VILLAS - LAS TERRENAS - SAMANÁ

4 - Approche fonctionnelle de l`entreprise 3 [Mode de compatibilité]

VENTES - VILLAS - LAS TERRENAS - SAMANÁ

VENTES - VILLAS - PUERTO PLATA - SOSUA

locations - villas - las terrenas - samaná

locations - villas - las terrenas - samaná

LOCATIONS - VILLAS - LAS TERRENAS - SAMANÁ

LOCATIONS - VILLAS - LAS TERRENAS

Fiche syst`eme d`assainissement 2014 St

please read product instructions