Pourquoi un système ERP ou MRP traditionnel n'est pas nécessairement adapté à la gestion d'un projet

Un précédent billet soulignait la différence entre la « traditionnelle » fabrication sur commande et la fabrication par projet. Pour rappel, la fabrication sur commande est axée, bien évidemment, sur les commandes (bons de travail, planification de la production par exemple). La fabrication par projet inclut un nombre de « commandes » également (bons de travail, bons de commande, etc.) qui sont utilisées comme points de contrôle. Mais dans ce cas, la collecte et le reporting des informations sont permis par le biais d'un projet et de sa structure. La structure du projet, souvent définie dans un organigramme de tâches, suit les termes et les étapes clés d'un contrat, et assure le reporting, la facturation (facturation proportionnelle et coût d'achèvement) et le suivi de la planification requis.

Pour simplifier au maximum, les bons de travail et de commande sont rattachés à des éléments spécifiques de l'organigramme, et les coûts et les étapes réalisées sont passés de la commande à l'organigramme par ce biais. Le reporting du statut du projet se fait à l'aide de l'organigramme, qui est relié à un calendrier (un graphique PERT par exemple).

Même si ce dispositif simplifié relie les coûts et les étapes de planification au projet, il ne répond pas à certains besoins de matériel et de comptabilité qui font partie intégrante de nombreux contrats, en particulier ceux pour le gouvernement, l'armée ou l'aéronautique.

La plupart des contrats gouvernementaux nécessitent une comptabilité précise de tout ce qui est acheté ou fabriqué pour un contrat donné. Ainsi, une pièce achetée ou fabriquée pour un contrat A doit être réservée et suivie dans le cadre du contrat A et ne peut être utilisée pour un contrat B ou mêlée à des pièces d'autres contrats ou de stocks différents. Cela va complètement à l'encontre de l'approche de base MRP ou ERP qui considère qu'une pièce est seulement une pièce et peut être utilisée n'importe où en fonction des besoins. La logique MRP doit être révisée (en mettant de côté la logique de quantité économique et de disponibilité de base) pour séparer les pièces des différents contrats et se plier aux contraintes de responsabilités et de comptabilité financière. Ou alors, chaque contrat doit être traité comme si c'était une usine à part entière, séparée des autres (plusieurs « cas » ou « environnements » MRP). Il existe autrement des règles ou des procédures qui permettent d'emprunter et de remplacer du matériel d'un contrat à un autre, mais le processus est assez fastidieux et nécessite une documentation approfondie. En outre, « emprunter/remplacer » ne supprime pas la nécessité de restreindre la logique MRP comme indiqué ci-dessus.

En conclusion, il est très difficile d'intégrer de force un système MRP/ERP « standard » dans un environnement de projet car il ne possède pas la structure et le reporting de projet nécessaires, et ne répond pas aux besoins de responsabilité, de comptabilité et de matériel de nombreux contrats gouvernementaux.

Si vous travaillez dans la fabrication par projet, votre système ERP s'intègre-t-il dans votre environnement ou devez-vous trouver des solutions de contournement ou effectuer vos activités de reporting en dehors du système pour répondre aux exigences de vos clients ?