Pourquoi votre tableur d'ordonnancement BPF coûte plus cher qu'il n'y paraît
Un blocage QA tombe le mardi, quelqu'un passe presque une journée à reconstruire la semaine à la main, et le plan de production qui sort au bout du compte est le premier qui fonctionne plutôt que le meilleur possible.
Le tableur n'est pas le problème en soi. Le problème, c'est ce qui se passe chaque fois que la réalité change et que le plan de production doit changer avec elle. Un blocage QA tombe le mardi, et quelqu'un passe presque une journée à reprendre à la main chaque dépendance en aval. C'est pour cette raison que le plan de production qu'un site applique réellement est le premier qui fonctionne, et non le meilleur possible. Cet écart se traduit avec le temps par de la capacité perdue, des enquêtes plus longues, et une fonction d'ordonnancement incapable de survivre au départ de son seul expert.
Le coût de la reconstruction : une journée, à chaque perturbation
Un temps d'attente après nettoyage arrive à échéance le jeudi matin. Un blocage CQ tombe le mardi après-midi. L'un comme l'autre oblige quelqu'un à reprendre à la main chaque dépendance en aval dans le classeur, à vérifier chaque déplacement par rapport à des contraintes dispersées dans des colonnes que personne n'a étiquetées pour cet usage, et à produire une réponse exploitable avant que le quart suivant ne planifie sur cette base.
Faites le calcul sur une année et le véritable coût n'est pas les heures perdues sur une reconstruction donnée. C'est la qualité du plan de production à laquelle le site renonce, faute de temps pour se demander s'il existe une meilleure séquence.
Un seul fichier, sans propriétaire ni mémoire
Demandez à cinq personnes d'un site d'ouvrir « le plan de production » et comptez le nombre de versions qui remontent. Le conditionnement travaille sur le fichier de mardi. La fabrication a celui de jeudi. L'alignement tient jusqu'à ce que la perturbation suivante le rompe à nouveau.
Le problème de fond, c'est l'endroit où réside réellement la logique d'ordonnancement. La règle selon laquelle un changement de format exige 90 minutes. L'hypothèse qu'une campagne ne peut pas dépasser neuf lots. Le jugement sur la suite de production qui absorbera un retard en premier. Rien de tout cela n'existe sur papier. Cela vit dans des formules construites par une seule personne, et dans une façon de penser qui réside dans la tête de cette personne.
Quand ce planificateur est en arrêt maladie, le plan de production se dégrade en silence. Quand il part, le site ne perd pas un tableur. Il perd le seul modèle opérationnel de son propre fonctionnement, et il n'en existe aucune version écrite à transmettre à la personne suivante.
C'est un point de défaillance unique au cœur de la capacité de production, et non un simple problème de personnel.
Une enquête sans rien à enquêter
C'est ici que les deux premiers coûts en engendrent un troisième, et c'est celui sur lequel il est le plus difficile de revenir.
Quand une formule est ajustée, qu'un temps d'attente est allongé, qu'une erreur d'arrondi est corrigée, le classeur n'en garde rien. Aucun nom, aucun horodatage, aucune raison. Rien de tout cela ne se voit tant que rien ne tourne mal.
Le jour où cela arrive, qu'il s'agisse d'un lot séquencé sur une hypothèse périmée ou d'un changement de format raccourci par une formule que personne ne se rappelle avoir touchée, la déviation doit quand même faire l'objet d'une enquête, et cette enquête doit aboutir à une cause racine. Une déviation qu'on ne peut pas relier à son origine, parce que l'outil qui l'a provoquée n'a laissé aucune trace, ne se clôture pas plus vite du fait d'être informelle. Elle s'enlise, elle est escaladée, et elle consomme bien plus de temps QA que la prévention de l'erreur initiale n'en aurait coûté. Le tableur n'a pas créé la déviation. Il a supprimé la capacité de l'expliquer, et c'est là le problème le plus coûteux.
Ce que le verrouillage du fichier règle, et ce qu'il ne règle pas
Combler les trois écarts suppose de sortir la logique d'ordonnancement du classeur pour la porter dans un modèle de contraintes spécifié qu'un solveur applique directement : chaque temps d'attente, chaque règle de changement de format et chaque contrainte de qualification respectés simultanément, avec un moteur de réordonnancement qui reconstruit la semaine automatiquement lorsqu'un blocage ou un arrêt survient, au lieu de coûter une journée à un planificateur.
Cinq questions à poser cette semaine
Deux réponses « non » ou plus signifient que le classeur d'ordonnancement coûte plus cher qu'il n'en a l'air.
- Si la personne qui a construit le plan de production partait demain, quelqu'un d'autre pourrait-il établir le plan de la semaine suivante sans reconstituer sa logique de zéro ?
- Après le dernier blocage ou arrêt imprévu, combien de temps la reconstruction a-t-elle pris, et pouvez-vous citer le chiffre ?
- Pouvez-vous produire, maintenant, la raison réelle pour laquelle un lot donné a été produit au moment où il l'a été ?
- Existe-t-il une seule version courante du plan de production, ou chaque fonction garde-t-elle la sienne ?
- À quand remonte la dernière fois où quelqu'un a eu le temps de se demander s'il existait une meilleure séquence, plutôt que de se contenter d'une séquence viable ?
Alexandre Clarizio est fondateur et PDG de Kaster Technologies, qui développe AIM, une plateforme d'intelligence décisionnelle pour la fabrication pharmaceutique BPF.
Questions fréquentes
- Que coûte un ordonnancement de production sous Excel à un site BPF ?
- Le coût direct est le temps des planificateurs perdu en reconstructions manuelles après chaque perturbation, soit près d'une journée par événement. Le coût le plus lourd est une capacité que personne ne voit : faute de marge pour optimiser, les sites appliquent le premier plan de production réalisable au lieu du meilleur, ce qui se traduit par des lots manqués et un débit moindre sur les lignes sous contrainte.
- Pourquoi un tableur verrouillé et à accès contrôlé ne suffit-il pas ?
- Le contrôle d'accès règle la question de savoir qui peut modifier le fichier. Il ne règle ni la durée d'une reconstruction, ni l'absence de documentation de la logique enfouie dans les formules. Ces deux écarts sont à l'origine du coût de reprise et du risque de point de défaillance unique.
- Un tableur d'ordonnancement de production doit-il être validé selon les BPF ?
- Cela dépend de ce que le tableur décide. Un outil d'aide à la planification qui n'alimente aucun enregistrement soumis aux BPF se situe hors périmètre de validation dans la plupart des cas. Dès lors que des formules calculent des temps d'attente avant ou après nettoyage qui déterminent le moment d'événements contrôlés, l'absence de piste d'audit devient un problème d'intégrité des données, que le fichier soit formellement dans le périmètre ou non.
- Remplacer le tableur d'ordonnancement implique-t-il de remplacer l'ERP ?
- Non. L'ERP conserve les données de référence, la planification de la demande et les ordres de fabrication, et il fait bien ce travail. Une couche d'ordonnancement lit depuis l'ERP sans y réécrire.
- Que deviennent les tableurs existants pendant une transition ?
- Ils deviennent la matière première. Le classeur est l'enregistrement le plus complet qui existe de la logique d'ordonnancement réelle d'un site, même si personne ne l'a construit comme de la documentation. Extraire cette logique dans un modèle spécifié est le premier livrable de la transition, et non quelque chose dont on se débarrasse à la fin.