23 mars 2013

A quoi sert le module Gestion de Production de votre ERP ?

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

Il y a quelques années, j'aurais choisi pour titre à cet article : "à quoi sert votre GPAO ?". Les technologies ont évolué et nos anciennes GPAO (Gestion de Production Assistée par Ordinateur) sont devenues une partie d'un ensemble plus vaste : l'ERP. C'est un progrès indéniable dont la première vertu est de doter l'organisation d'une base de données cohérente pour supporter des processus transversaux qui impliquent tous les métiers de l'entreprise.

Dans la plupart des ERP, les modules qui couvrent les processus de supply chain management sont construits sur le modèle MRP2. Malgré que les principes de ce modèle soient enseignés depuis quelques décennies maintenant, que nous autres consultants nous efforçons de les diffuser le plus largement possible, j'ai l'impression que, dans beaucoup d'entreprises, on a une fâcheuse tendance à les oublier… (Voir à ce propos mon article «MRP moins 2, ou la dégénérescence des ERP»). Chaque service de l'entreprise interprète alors à sa façon l'utilisation de l'ERP. N'étant pas utilisé de façon appropriée, le système perd sa cohésion et n'est pas capable d'apporter l'aide qu'il est censé apporter. Face à ces déficiences, chacun conclut que l'ERP ne sert à rien sauf à compliquer le travail quotidien. Comme chacun a néanmoins besoin de gérer une masse considérable d'informations, les feuilles de calcul s'épanouissent un peu partout (c'est normal, c'est le printemps !). Dans beaucoup de sociétés le fameux tableur de Microsoft est plus souvent utilisé que l'ERP...

Voici quelques exemples pour illustrer mon propos :

Dans cette société, ce sont des gammes de fabrication dont les temps sont établis à partir des objectifs de coût de revient. Les coûts réels doivent correspondre aux coûts standards puisqu'ils constituent les objectifs de la production. Or, la pression sur les coûts conduit à fixer des objectifs de temps certes ambitieux, mais inatteignables s'il n'y a pas de plan d'actions conséquent et cohérent avec les objectifs. On devrait toujours s'assurer de l'équation : temps objectifs = temps démontrés + plan d'actions. Dans le meilleur des cas, le plan d'actions existe, mais on intègre d'emblée son résultat, alors que la mise en œuvre des actions prend souvent de longs mois. Dans le pire des cas… il n'y a pas de plan d'actions structuré. En conséquence, les calculs de charge, qui devraient servir à s'assurer de l'équilibrage entre les charges et les capacités, sont faux et inexploitables ! On reconstruit alors une base de données sur un tableur pour disposer d'un calcul de charge exploitable. Ou pire, quand la culture "gestion de production" de l'entreprise est rudimentaire, on en conclut que ces calculs sont inutiles et on y renonce ! La gestion de production consiste alors à chasser les manquants et les retards !

Les données techniques, ici les temps gamme, doivent refléter ce que l'atelier est capable de faire. Les temps doivent être mis à jour en fonction de leur amélioration effective, pas pour obtenir des coûts de revient conformes aux objectifs.

La plupart des ERP permettent d'associer plusieurs gammes de fabrication à un article : la gamme par défaut est utilisée pour les calculs de charge. On peut alors utiliser une version spécifique de la gamme pour faire des calculs ou simulation de coût de revient. Et si l'ERP n'a pas cette fonctionnalité, vaut-il mieux condamner l'ensemble des décideurs de la production à développer des feuilles de calcul pour permettre à un contrôleur de gestion de calculer les coûts de revient qui lui conviennent ? Ou ne vaut-il pas mieux demander au contrôleur de gestion de reprendre les coûts issus de gammes réalistes dans son tableur pour les adapter à ses attentes ? Où se trouve la fréquence de recalcul la plus élevée ? Du côté du contrôle de gestion pour les coûts ou du côté de la production pour les calculs de charge ?

Dans une autre entreprise, les dates de réception des commandes fournisseur ne sont pas mises à jour. La raison : la date de livraison sur laquelle le fournisseur s'est engagé initialement est utilisée pour calculer l'indicateur de ponctualité du fournisseur. Donc, si on la modifie à chaque report de livraison, la ponctualité est toujours bonne ! Les conséquences de cette pratique sont désastreuses pour le calcul des besoins nets (CBN) qui devient alors inexploitable. Comme les approvisionneurs ont cependant besoin de connaître les "vraies" dates de livraison, ils construisent une base de données parallèle sur tableur dans laquelle ils maintiennent des dates de livraisons réalistes (voir aussi l'article «MRP2 moins 2»).

Dans ce cas, l'analyse est similaire à celle que j'ai proposée pour les gammes de fabrication : la plupart des ERP permettent de distinguer la date de livraison initiale de la date de livraison planifiée. Et quand bien même cette fonctionnalité n'existe pas, vaut-il mieux laisser les approvisionneurs maintenir au jour le jour une base de données sur tableur et sacrifier la pertinence du CBN (rien que ça !) ou demander à un acheteur de mettre à jour une fois par mois un tableau permettant de calculer des indicateurs pertinents ?

Un dernier exemple avant de vous laisser présenter les vôtres en commentaire de cet article : dans une autre société (notez que bien souvent on trouve tous ces cas dans la même entreprise !), la comptabilité a demandé de créer deux codes articles distincts, A et B, pour le même article. La raison : ce composant est fabriqué à la fois pour les besoins de l'atelier d'assemblage (article A) et pour les besoins d'un client (article B). Or, on veut pouvoir distinguer deux stocks différents d'un point de vue comptable. Quiconque connaît les principes du CBN imagine bien la conséquence d'une telle pratique : le CBN proposera de fabriquer des articles B si le stock ne couvre pas les besoins, même si par ailleurs on a des articles A en stock. Dans une telle situation, on peut plus simplement créer deux magasins différents, dont on sait valoriser les stocks, et prendre en compte ces deux magasins dans le CBN.

En conclusion, ces mauvaises pratiques ont des conséquences désastreuses :

  • La supply chain est mal gérée, les clients sont mal servis et les stocks prolifèrent,
  • Les mauvaises pratiques génèrent un nombre considérable d'activités sans valeur ajoutée qui grèvent la compétitivité de nos entreprises,
  • Elles amènent les employés à considérer que l'ERP est inutile et à promouvoir les initiatives locales (tableurs) qui entrainent l'entreprise dans un terrible cercle vicieux : moins on utilise correctement l'ERP, moins il est efficace, et moins il est efficace, moins on est tenté de l'utiliser correctement.

Pour éviter de telles situations, les managers doivent adopter deux principes :

  • L'acquisition des bonnes pratiques du modèle MRP2 ne se fait pas en suivant une seule formation. Les managers doivent organiser, en plus des programmes de formation initiale, des séances de révisions régulières, en faisant appel à des experts internes ou externes. Il ne faut pas considérer que les bonnes pratiques sont définitivement acquises après une première formation.
  • Les managers doivent connaître le détail des tâches accomplies par leurs collaborateurs. Les managers qui ne savent que superficiellement ce qu'accomplissent leurs collaborateurs ne peuvent pas détecter les dérives dans leurs pratiques et réagir en les ramenant vers les fondamentaux.

Commentaire(s) sur "A quoi sert le module Gestion de Production de votre ERP ?"

  1. Bonjour Xavier,
    d'abord un grand merci pour cette synthèse et ces rappels, ... comment dire, cruciaux !

    Un de mes mentors avait coutume de dire qu'il faut rationaliser les pratiques avant de mettre en place un système d'information, sinon on automatise les bêtises (il utilisait un autre mot commençant par "c...") : "Si on fait le contraire on fait dix fois plus de choses stupides qu'avant et on les fait dix fois plus vite..."

    Je souhaite enfoncer "le clou" (eh, oui, là aussi...) en insistant sur 2 clés issues de mon expérience de mise en place d'une vingtaine d'ERP , petits et grands :

    1 - La maîtrise des "données de base" (articles, clients, fournisseurs, nomenclatures, gammes, centre de charges, paramètres de planif...) doit devenir une activité de l'entreprise à part entière (voir le nouveau processus "Enable" du SCOR 2013) incluant les activités de tenue à jour, garantie d'unicité, surveillance d'intégrité, nettoyage mais surtout avec des règles de gestion calées sur les bonnes pratiques pour chaque champ. Cela coûte (temps, ressources), cela nécessite une surveillance centralisée mais cela rapporte BEAUCOUP en choses stupides évitées et en gaspillages de toutes sortes.

    2- La définition des KPI lors de la mise en oeuvre d'un ERP devrait répondre de la même rigueur que les "master data". Trop de solutions "boite noire" ne pemettent plus de savoir comment un indicateur est calculé avant de sortir de la machine. Même l'utilisation de "Business Intelligence" sophistiquée ne permet pas de garantir l'unicité et la cohérence des chiffres si les règles de gestion en sont pas claires. Là aussi, il faut éviter de réinventer la roue et utiliser les bons indicateurs, comme ceux du modèle SCOR, et surtout en utiliser moins (maximum 3 à 5 doivent suffire pour un niveau hiérarchique, dont au moins 1 à 2 commun avec les niveaux hiérarchiquex du dessus et du dessous)

    Un exemple pour finir, vécu pour illustrer un réponse à la question : dans un secteur de fabrication en petite série, un assembleur était systématiquement en retard et n'arrivait pas à planifier le travail de ses fournisseurs rang 1 et rang 2. Une analyse rapide a révélé que l'ERP était mal paramétré :

    a. les éléments de sécurité avaient été tous activés pour la planification des ordres d'achat (délai sécurité / stock de sécurité / temps d'activation de commande / temps de réglage)

    b. à chaque "MRP run", tout étant très en retard du fait des différentes sécurités paramétrées, les utilisateurs avaient pris l'habitude de "overrider" les messages d'alerte et ne tenait plus compte des dates proposées, préférant se fier à leur jugement et se complaisant dans des activités de "pompier qui sauve la planète" chaque jour

    Moralité, l'ERP ne servait pas à grand chose, si ce n'est consommet de l'énergie à tout le monde sans apporter le service qu'il était censé rendre. En désactivant tous les paramètres et en en gardant 1 seul pour gérer les aléas (un stock de sécurité calculé au plus juste et piloté par le terrain), les choses sont rentrées dans l'ordre en 6 mois.

    Merci encore Xavier pour avoir remis le doigt sur ce sujet si important et parfois si "simple" à détecter...

    Amicalement
    Frederic Gaurier

  2. Salut Xavier,

    J'ai aussi rêvé qu'un ERP soit une machine à créer et réaliser les plans d'actions à partir de l'écart entre la réalité et les données rêvés qu'on lui injecte...J'ai aussi rêvé qu'un APS me propose un système parfaitement optimisé...

    Et puis un jour, jen ai eu assez de faire le pompier toute la journée et d'être déçu que mes projets ne tiennent pas leurs promesses.

    J'ai changé mes rêves...Cela n'a pas été facile. J'ai du revoir des certitudes veilles de plus de 30 ans, d'autant plus ancrées, qu'elles étaient partagées par la plupart d'entres nous, même si les résultats n'étaient pas toujours présents.

    J'ai regardé la réalité et ses interdépendances (j'ai appris que la capacité en compétence dépend de la charge quand on développe la polyvalence). Je me suis mis à trier les idées de la pensée unique (Que faire du takt time et des VSM quand on travaille en job shop en Low volume high mix?). J'ai aussi appris à lire comment fonctionne un système, à faire confiance, à créer une vision partagée, à faire grandir...Tout cela pour quoi ?

    Pour créer rééllement de la valeur. Et qui est à la source de la valeur ? Pour moi, ce n'est jamais les outils. C'est les compétences des hommes...

    Il me semble que c'est bien plus l'éducation que l'on reçoit et les croyances associées qui nous limitent que les lois de notre pays. Fort de cette croyance, je vais m'investir de plus en plus, pour partager mon expérience en supply chain et en management basé sur une approche systémique...Je sens que c'est ma mission 😉 !

    Merci encore Xavier pour la qualité de ton blog...
    Quand est ce que tu sors ton livre ?

    A, bientôt,
    Cédric

    1. Merci Cédric pour ce commentaire.
      En ce qui me concerne, les ERP, et encore moins les APS, ne m'ont jamais fait rêver !

  3. Bonjour Xavier,
    Encore un excellent article qui à l'énorme mérite du pragmatisme, dans un monde ou tout devrait être conceptualisé.
    Pour réagir à 2 points que tu as évoqués dans ton article, et en tant qu'ancien intégrateur d'ERP et de consultant AMOA, je note 2 axes :
    - J'ai toujours été effaré qu'aucun client ne soit réceptif à la proposition que nous lui faisions lors des missions d’intégration et qui consistait à lui proposer une requête spécifique (malheureusement qui n'existe pas en standard) et qui consistait à mesurer les temps de gammes le plus réel sur la base des horodatages des OF et de les comparer aux données de la gamme en tant que données de base. Idem pour les délais de fabrication, d'attente ou de livraison réels vs les données de la base article
    - L'exploitation des messages d'exception des ERP est toujours largement sous-estimée, la formation des planificateur en charge de leur interprétation et de leur résolution étant très largement négligée, car arrivant après la consommation de l’intégralité des budgets d’intégration du projet. Un client un jour m'a même demandé de quoi je lui parlait 'Les messages de quoi???'
    Je pense que ces deux axes d'amélioration lors de la mise en oeuvre de nouvel ERP, ou lors d'optimisation de leur fonctionnement sont complètement oubliés par la majorité des industriels, si j'en juge par le nombre ridicule de missions que nous avons eu à réaliser sur ces deux sujets, alors qu'ils sont peu coûteux et vecteurs d'amélioration immédiates et durables. Vous avez dit compétitivité nationale ?

    Frédéric BILLON-GRAND
    Confluence Management

  4. Bonjour Xavier,

    He oui tu résume très bien ce que nous vivons au quotidien:

    Les ERP sont devenus plus compétents et réaliste que les utilisateurs ou en d'autres mots on mets dans les mains des entreprise des outils puissant que les utilisateurs n'apprennent pas à maîtriser.

    Cela devient comme si on mettait dans les mains de quelqu'un une formule 1 alors qu'il a a peine son permis de conduire.

    Je suis d'accord avec les posts ci-dessus et pour ma part j'ajouterai que lors des déploiements d'ERP quand je propose des formations métiers en complément des procédures d'utilisation on me répond toujours " A quoi ça sert - la procédure suffit"...

    Amicalement
    Alain

  5. Est-il besoin de souligner encore le pragmatisme et le parler vrai - et simple - de Xavier ?
    J'ajoute mon annecdote vécue dans le milieu aéronautique.
    Le paramétrage d'un délai d'obtention (cycle de fabrication) dans un ERP était à 45 jours. Or, le délai avéré ressortait régulièrement autour de 65 jours. Evidemment les OF étaient toujours en retard. A la question : pourquoi ne pas paramétrer les 65 jours réels ? ; il m'a été repondu : si l'on paramètre 65, "ils" vont en mettre 85 !...
    Je rappelle le nécessaire recours aux CRS : Cohérence, Rigueur, Simplicité. Qui doivent se substituer aux situations solidements implantées: Co-errance, Système D, Usine à gaz.
    Amis missionnaires - porteurs de la bonne parole - Salut !

  6. Merci pour cet article. Il faut reconnaître que certaines entreprises ont sans doute une grande difficulté à faire usage des ERP. Je crois qu'elles doivent penser à mettre en place des séances de formation afin que leurs employés puissent s'y habituer sinon elles perdent leur temps et leur argent pour un résultat négatif.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.

Categories

Archives