MRP moins 2... ou la dégénérescence des ERP

Par Xavier Perrin (xperrin@xp-consulting.fr)

Introduction

L'amélioration du taux de service et la réduction des délais et des stocks sont le lot commun des entreprises industrielles. Deux approches développées au cours des dernières décennies ont considérablement fait progresser leur aptitude à relever ces défis :

L'avènement des technologies informatiques a permis l'émergence d'outils de planification "assistés par ordinateur". Ainsi J.Orlicky, créateur des premiers algorithmes de calcul de besoins nets (MRP) dans les années 60, a posé les bases sur lesquelles, en collaboration avec O.Wight et G.Plossl, été de développée l'architecture MRP2 (Planification des Ressources de la Production) reprise par nos modernes ERP. Le développement continu de la puissance de nos ordinateurs et des techniques de programmation a donné naissance aux APS, outils de planification sous contrainte, toujours plus performants.

Parallèlement, le Système de Production Toyota formalisé par Taiichi Ohno, puis popularisé par les recherches du MIT et le célèbre ouvrage de J.Womack, D. Jones et D.Roos "The machine that changed the world", a mis à disposition des industriels une philosophie et des outils qui leur ont permis de considérablement améliorer leur performance en terme de qualité, de coûts et de délais.

Et pourtant, quel contraste entre les promesses de ces techniques et ce qu'on observe dans beaucoup de nos entreprises. Alors qu'elles ont investi des sommes colossales pour se doter des meilleurs ERP, le principal outil effectivement utilisé par les équipes chargées de la logistique et de la gestion de production est… le tableur ! Inutile de compulser les revues spécialisée pour connaître le numéro un des ERP : il est édité par Microsoft et s'appelle Excel !

Faut-il en conclure que nos ERP sont défaillants ? Qu'ils ne répondent pas aux enjeux de nos entreprises ? Nombreuses sont les critiques, voire les sarcasmes, adressés à ces technologies. Bien souvent, on n'hésite pas à leur faire porter la responsabilité de la mauvaise performance de nos entreprises. C'est par ailleurs une accusation fréquente proférée par des confrères qu'on qualifie parfois de "gourous" du lean manufacturing… Il faut toujours se méfier des gourous, fussent-ils experts en lean manufacturing…

Plus de 25 années passées dans l'industrie, dont une bonne douzaine d'années comme consultant, me permettent de répondre avec assurance qu'un ERP (je veux parler ici de ceux qui font référence bien sûr, pas des impostures d'ERP) n'est jamais la cause des déboires d'une entreprise. Quand l'ERP est montré du doigt, il faut rechercher la vraie cause des dysfonctionnements dans deux directions :

1. La façon dont l'ERP a été implémenté, et partant, la compétence de ceux qui l'ont mis en place (équipe projet, intégrateur…)

2. La façon dont l'ERP est utilisé, et partant, la compétence des utilisateurs et surtout, celle de leurs responsables.

C'est ce deuxième point que je développerai dans cet article.

Rappel à propos de MRP2

Le propos de cet article n'est pas de faire une Nième description de ces concepts : la littérature est pléthorique en la matière. Il faut juste lire les bons ouvrages... en privilégiant ceux écrits par des CPIM !

L'architecture d'un système de planification est décrite ci-dessous. Je voudrais m' attarder sur les flèches (en rouge sur le dessin) qui relient les différents rectangles, et qui constituent la "substantifique moelle" du système de planification MRP2.

Comme on peut le remarquer, les flèches rouges sont des doubles flèches : elles relient les rectangles dans les deux sens.

Prenons l'exemple des flèches qui relient les rectangles "PIC "et "Planification des Besoins en Ressources". Cela signifie que lorsqu'un plan de production a été construit au cours du processus PIC (volumes mensuels de production par familles sur un horizon de 18 mois au moins), on projette les "besoins en ressources" générés par le plan pour les ressources critiques. Lorsqu'un déséquilibre entre les besoins en ressources et les capacités est mis en évidence, deux solutions sont envisageables (en général, c'est une combinaison des deux solutions qui est retenue) :

• Soit on peut ajuster les capacités des ressources dans l'horizon, auquel cas le plan peut être validé,

• Soit on ne peut pas adapter les capacités des ressources dans l'horizon, et il faut réviser le plan avant de le valider.

La double flèche indique donc que le rectangle "PIC" pilote le rectangle "Planification des Besoins en Ressources" (flèche vers la droite) et que le rectangle "Planification des Besoins en Ressources" contraint le rectangle "PIC" (flèche vers la gauche). Bien entendu, ces flèches représentent bien plus que des transferts d'information. Certains d'ailleurs voient avant tout le système MRP2 comme un système d'information, ce qui est pour le moins réducteur et à l'origine de bien des déconvenues (voir mon article "L'illusion du temps réel") . Les flèches indiquent que des décisions doivent être prises : le système de planification est d'abord un processus de décisions, qui doivent bien sûr être prises par les bonnes personnes. Par exemple, s'il faut ajuster les capacités de certaines ressources critiques, c'est une décision qui engage le plus haut niveau de responsabilité de l'entreprise. De la même façon, si le plan de production, le plan des ventes ou le plan de stock doivent être reconsidérés, cela engage les directions concernées et, bien sûr, la direction générale.

Si on considère maintenant les rectangles "PIC" et "PDP", la flèche descendante indique que le "PIC" pilote le "PDP", c'est-à-dire, que le programme de production (références, quantités, périodes) doit s'inscrire dans le plan de production de la famille concernée. Il arrive que, compte-tenu de la réalité de la demande client à court terme, et/ou de la réalité du mix produit, et/ou des contraintes de capacité mises en évidence dans le rectangle "Vérification Globale des Charges ", le PDP ne s'inscrive pas dans le cadre du plan de production. Dans ce cas, c'est la flèche montante du rectangle "PDP" vers le rectangle "PIC" qui contraint le PIC : le plan de production doit être révisé.

Ce mécanisme se répète à tous les niveaux du système de planification. Il représente les processus de décision qui constituent l'essence même d'un système de planification.

Lorsque les "flèches" ne jouent pas leur rôle, c'est-à-dire lorsque les décisions ne sont pas prises au bon moment et par les bonnes personnes, le processus de planification est défaillant, quelque soit l'ERP qui le supporte.

Dans la suite de cet article, je m'attarderai sur un "classique" du dysfonctionnement du système de planification, particulièrement désastreux pour la performance de l'entreprise (taux de service, stocks) et pour l'efficience et l'efficacité des équipes chargées des approvisionnements et de l'ordonnancement. Nous allons donc regarder de plus près les flèches qui relient les rectangles "PDP", "CBN", "Calcul des Besoins en capacité" et "Exécution et pilotage des opérations".

Observations

Toute ressemblance entre les situations décrites ci-dessous et la réalité de ce qui se passe dans votre entreprise n'est pas fortuite.

Imaginons une entreprise qui fabrique ses propres produits par l'assemblage de composants et de sous-ensembles qu'elle fabrique dans ses ateliers et qu'elle approvisionne chez des fournisseurs. L'entreprise en question dispose d'un ERP de qualité : il couvre de façon pertinente l'ensemble du système de planification. Certes, il n'est pas de première jeunesse et son ergonomie est quelque peu dépassée…

Les personnes chargées des approvisionnements, leur collègues chargés de l'ordonnancement et du suivi de fabrication, sont devenues expertes dans l'utilisation de Microsoft Excel : c'est une nécessité car les listes de priorité établies pour les ateliers par les techniciens d'ordonnancement, les listes de manquants avec les dates de mise à disposition communiquées aux planificateurs par les approvisionneurs, les calculs de charge réalisés par les techniciens d'ordonnancement pour les responsables d'atelier et le responsable de la logistique, tous ces documents sont établis avec Excel à partir d'extractions de la base de donnée de l'ERP. Pourquoi n'utilise-t-on pas les documents et états générés par l'ERP ? Sont-ils tellement mal présentés, peu lisibles, qu'on ne saurait les exploiter ? Non, les états de l'ERP ne sont pas utilisés car ils sont "faux" ! Et en quoi sont-ils faux ? Réponses :

• Les listes de manquants communiquées aux planificateurs, pour qu'ils puissent programmer la fabrication des produits-finis, indiquent principalement des dates de mises à disposition "dans le retard" qui sont bien sûr inexploitables.
• Les listes de priorité établies pour les ateliers ne reflètent pas la réalité des priorités. Les "vraies" priorités sont définies par une "liste stratégique", qui n'est pas gérée avec l'ERP…
• Les graphiques de calcul de charge générés par l'ERP sont inexploitables car ils montrent que l'essentiel de la charge de travail est située… dans le passé.

Le taux de respect du PDP n'est pas mesuré, mais chacun sait très bien qu'il est déplorable. D'ailleurs, lorsque la situation devient ingérable, même avec Excel, on procède à un grand nettoyage qui consiste à "recaler" le PDP : les fabrications sont reprogrammées avec des délais "réalistes" afin de faire disparaître le retard devenu ingérable. En moyenne, on procède à deux "nettoyages" par an. Tout le monde apprécie les semaines qui suivent ces nettoyages : on travaille enfin avec des informations "réelles". Mais la sérénité de dure pas : bientôt, la gangrène du retard refait surface et pollue tous les documents. Même ceux générés par Excel. Tout ça, c'est la faute :

• Des ateliers qui ne respectent pas les priorités,
• Des fournisseurs qui livrent toujours en retard,
• De ce foutu ERP complètement dépassé…

Désespéré par l'incapacité de ses équipes à correctement planifier les fabrications, à respecter leurs engagements quand on leur demande "quand pourras-tu mettre à disposition les composants dont nous avons besoin ?", par les reproches incessants des commerciaux qui ne comprennent pas qu'on ne puisse pas livrer à l'heure… le responsable de la logistique me demande si je connais un ERP qui serait adapté à la situation et qui permettrait enfin de résoudre tous ces problèmes…

Analyse

L'entreprise en question a besoin, pour résoudre ses dysfonctionnements, d'un ERP qui supporte le système de planification MRP2. Or, cet outil, elle l'a depuis 20 ans… certes, il n'est pas tout jeune et un peu ringard avec ces écrans et interface style "AS400". Mais toutes les fonctionnalités MRP2 existent et sont correctement construites.

Bien sûr, une première condition pour que notre entreprise puisse exploiter correctement son ERP est que les données qu'elle gère soient exactes. C'est le bon vieux principe du GIGO (Garbage In Garbage Out)… Les processus garantissant l'exactitude des données statiques et dynamiques doivent être en place et opérants. Je ne développerai pas ce point dans cet article, que d'autres ont largement traité par ailleurs. Qui plus est, ce n'est pas le principal point faible de notre entreprise. Le problème de notre entreprise se trouve au niveau des "flèches rouges" présentées plus haut. Ici, les flèches n'existent que dans un sens. Le système MRP2 est exploité en "boucle ouverte". D'où le titre de cet article…

Le processus PIC est défaillant : on se concentre sur les objectifs à court terme, et on élude les questions posées par l'équilibrage offre / demande à moyen terme.

Le PDP est considéré comme un objectif qui ne saurait être remis en cause par la réalité des approvisionnements et de la fabrication : les ateliers et les fournisseurs doivent "se débrouiller" pour réaliser le PDP, qui n'est pas "négociable". Par ailleurs, la vérification globale des charges réalisée au niveau du PDP n'est envisagée que pour permettre aux ateliers de "s'adapter". Il n'est pas question qu'elle conduise à la remise en cause du PDP.

Une "règle de base" énoncée par la direction de la logistique est :  "il est interdit de rejalonner un ordre de fabrication ou une commande d'achat". Cela conduirait à "entériner" les retards. Qui plus est, on perdrait la priorité relative des besoins. Et ce qui est en retard de deux semaines est bien sûr prioritaire par rapport à ce qui est en retard d'une semaine seulement. Et de toutes façons, la "liste stratégique", établie par les planificateurs et validée par la direction, doit être la référence absolue.

Cette règle, c'est la mort du système de planification. Par cette règle, on élimine la flèche montante de l'exécution vers le CBN, ainsi que la flèche montante du CBN vers le PDP. On met en place le système "MRP moins 2" en boucle ouverte. On fait dégénérer l'ERP qu'on qualifiera ensuite de tous les noms…

En effet, le principe de base du CBN est de jalonner des ordres planifiés à partir :

• Des besoins bruts
• Des réceptions attendues
• Du stock disponible au moment du calcul (déduction faite des réservations).

Les réceptions attendues n'étant pas positionnées correctement, et principalement dans le passé, le CBN n'est pas capable de donner d'indications pertinentes pour les périodes à venir.

Autre effet pervers de cette pratique : on perd une information essentielle offerte par le CBN : la notion de dépendance horizontale. La dépendance horizontale, c'est la possibilité de relier la date du besoin de deux composants rattachés au même niveau d'une nomenclature. Par exemple, si on fabrique des tondeuses à gazon, le besoin des roues est dépendant du besoin du moteur. En effet, si on décide d'avancer, ou de reculer, la mise à disposition du moteur, alors le besoin pour les roues est également modifié, même si on n'a pas besoin des roues pour assembler le moteur. Mais comme l'assemblage de la tondeuse dépend de la disponibilité du moteur et des roues, ces articles sont liés. C'est une fonctionnalité indispensable pour gérer les "vraies" priorités des ateliers et des fournisseurs.

Lorsque ces fonctionnalités sont défaillantes, on compte alors sur Excel pour fournir ces informations, ce qu'il est bien incapable de faire…à moins d'y reprogrammer tous les algorithmes du CBN.

Certes, quand un atelier ou un fournisseur est en retard, il ne s'agit pas de prendre acte de ce retard et de systématiquement reprogrammer le PDP. Cependant, quand un retard est observé, il ne saurait être résolu par une injonction telle que "débrouillez-vous" (je garde volontairement un style édulcoré pour cet article, qui ne reflète probablement pas la réalité du terrain !). Une telle injonction n'a jamais résolu un problème de retard. Je ne connais que deux possibilités :

• Soit la cause du retard est identifiée et on est capable d'imaginer et de mettre en place les dispositions qui permettront de résoudre le retard (elles doivent être documentées et suivies pour avoir une chance d'être efficaces),
• Soit la cause du retard est identifiée et on n'a pas la possibilité de résoudre le retard : la date de mise à disposition doit être reportée et mise à jour, et les conséquences sur les niveaux de planification supérieurs doivent être évaluées et prises en compte (flèche ascendante).

Lorsque cette pratique est rigoureusement respectée, l'ERP peut effectivement être exploité… même quand il est vieillot ! A contrario, si vous utilisez un ERP moderne sans mettre en œuvre les flèches ascendantes, il ne sera pas plus efficace que votre vieux système…

Solutions

L'exemple que je viens de décrire, aussi fictif soit-il, est suffisamment courant pour que j'aie pu en extraire la cause racine.

Exploitons la méthode des 5 pourquoi qu'on évoque si souvent dans le cadre de l'approche lean :

Nous avons compris que le dysfonctionnement ne vient pas de l'ERP, mais de la façon dont il est utilisé.

La question est donc : pourquoi (1) utilise-t-on aussi mal nos ERP ?

Une première réponse vient à l'esprit : car les gens qui s'en servent ne savent pas s'en servir.

Pourquoi (2) donc trouve-t-on autant d'employés incompétents à utiliser correctement leur ERP ? Voilà une chose surprenante quand on considère les budgets de formation accordés aux projets de mise en place d'ERP… Mais à y regarder attentivement, quelle est la part de ces programmes de formation consacrée au système de planification MRP2 et à l'importance des flèches rouges ?

Pourquoi (3) donc, malgré les efforts de formation accompagnant les projets ERP, consacre-t-on si peu de temps (voir pas du tout) à l'explication du système de planification MRP2 ?

J'apporte une double réponse à cette question (avec encore deux pourquoi !) :

D'abord parce que les intégrateurs, qui maîtrisent (en principe) parfaitement les fonctionnalités de l'ERP qu'ils installent ne maîtrisent pas pour autant le système de décision associé au système MRP2. Pourquoi (4) ? Parce que bien souvent, ils n'ont pas vécu eux-mêmes les prises de décisions associées au système de planification, et qu'il est très difficile d'en parler quand on ne l'a pas vécu…

Ensuite, parce que les responsables ou directeurs, chargés de la logistique, du supply chain management, voire de la direction industrielle, ne maîtrisent pas eux-mêmes les principes développés dans cet article. Ils ne peuvent donc pas s'assurer qu'ils sont correctement mis en œuvre par leurs collaborateurs. Pourquoi (5) ces responsables n'ont-ils pas ces compétences ? D'une part, parce qu'on n'insiste certainement pas assez sur ces compétences lorsqu'on recrute pour ces fonctions. D'autre part, parce que trop souvent, les responsables considèrent qu'ils n'ont pas à maîtriser les outils qu'utilisent leurs collaborateurs. Combien de fois ais-je entendu de tels responsables répondre : "débrouille-toi, c'est toi l'expert", à la question d'un collaborateur pourtant bien conscient que l'ERP est mal utilisé.

Un principe essentiel de l'approche lean porte sur le management : un responsable doit comprendre le travail détaillé de ses collaborateurs. Certes, il ne peut pas (ne doit pas) être un expert, mais il doit passer suffisamment de temps sur le terrain avec les personnes qu'il dirige pour comprendre l'implication de toutes leurs tâches et comprendre comment elles interagissent avec le reste de l'entreprise. C'est un principe fondamental qui, quand il n'est pas appliqué, conduit aux situations décrites ci-dessus.

Conclusion

Nous venons de comprendre comment l'incompréhension du système de planification MRP2 par les responsables d'une entreprise conduit inévitablement à la "dégénérescence" des meilleurs ERP. Or, étant donné que les plus hauts niveaux de management sont impliqués dans le processus de planification, il est indispensable que ces principes soient maîtrisés au plus au niveau. Mon confrère et ami Jean-Pierre Fauverghe, consultant associé Oliver Wight, aime à utiliser l'image de la pomme de Newton pour décrire une conséquence très dommageable de la gravité : lorsque les décisions ne se prennent pas là où elles devraient se prendre, elles "tombent" aux niveaux inférieurs, là où les personnes n'ont pas les éléments, ni le pouvoir, pour prendre des décisions pertinentes. Il est remarquable de constater que les personnes chargées des niveaux de planification "CBN" et "Exécution et Pilotage des Opérations" dépensent une énergie folle pour régler des problèmes qui auraient du être traités dans les niveaux "PIC" et "PDP". Outre la débauche d'énergie et les nombreux gaspillages (non-valeur ajoutée) générés par de telles situations, la plus dommageable des conséquences concerne les clients qui sont généralement les moins bien traités et les premières victimes de ces dysfonctionnements.