Les principes de base du kanban, ses différentes formes et la mise en oeuvre de cette méthode ont été traitées lors de précédents articles publiés sur le site du Pôle Productique. Nous évoquons, dans celui-ci, l'intégration du Kanban et de la GPAO. Dans quel cadre nous situons nous ?
Entreprise utilisant le kanban sur plusieurs centaines de références, ou ayant en projet de le faire, et disposant d'une GPAO.
Apport de l'informatique pour la gestion du kanban
Quelques rappels. Le calcul du kanban repose sur des données stables : Lot fabriqué, délai, sécurité, conditionnement, et une donnée variable : la Consommation Moyenne Journalière (CMJ).
Si implanter le kanban dans un atelier gérant quelques dizaines de références ne nécessitera qu'un tableur pour le calcul des étiquettes, il n'en va pas de même pour une généralisation comportant plusieurs centaines de références. Comment maintenir un dimensionnement du kanban réactif, en fonction de l'activité de l'entreprise ? Le problème est relativement simple pour une activité gérant un ou deux niveaux de nomenclature, mais au-delà...
Le véritable problème est peu dans le calcul et la réalisation des étiquettes, des solutions existent sur le marché, mais la régulière mise à jour du calcul kanban via la CMJ.
Comment calculer la CMJ ?
La CMJ doit être le reflet de l'activité commerciale, ou plus exactement du Plan Directeur de Production appliqué aux produits finis. Pour faire simple, considérons que nous avons une quantité moyenne mensuelle exprimée sur les produits finis, quantité exprimée par un mixte historique - carnet de commande - prévisions sur une période donnée, trimestre, par exemple. Nous disposons ainsi d'une CMJ sur les produits finis, et allons effectuer un Calcul de Besoins Brut pour la transposer sur chaque niveau de la nomenclature.
Nous voyons bien que sans la GPAO, il serait très difficile d'effectuer ce traitement pour remettre à jour la CMJ.
Malheureusement, peu de GPAO intègrent un Calcul de Besoins Brut... et encore faut-il pouvoir extraire les résultats sous forme de fichier pour les intégrer dans notre calcul d'étiquettes.
Moyennant un peu de réflexion et beaucoup de bon sens, il est toujours possible de trouver des solutions. C'est souvent là le seul « spécifique » que l'on va demander au prestataire informatique ou à l'équipe interne.
Attention : ignorer ce traitement et se contenter d'utiliser un historique de consommation pour chaque composant mis en kanban, amènera à coup sûr un risque de rupture ou de sur-stock, en cas de changement dans les nomenclatures (composant remplacé par un autre par exemple), de saisonnalité, etc. Donc le kanban a besoin de la GPAO.
Complémentarités entre Kanban et GPAO
Nous ne reviendrons pas sur l'apport du kanban dans les ateliers et magasins en terme de participation du personnel, de gains sur les stocks, etc. Notre débat est ciblé sur le rôle de chacun dans la gestion de production.
Que fait le kanban ?
Principalement, il déclenche un besoin lisible par les opérateurs et communique le programme de fabrication (que produire, quand)
En complément, il informe, dans l'atelier, de la situation des produits.
Il n'exige pas de précision dans la gestion des stocks par l'informatique.
Que ne fait pas le kanban ?
Aucune information historique, aucune prévision à moyen terme, et aucune valorisation.
Nous voyons bien que le kanban va gérer le court terme en amenant la décision au plus proche du terrain, avec une très forte réactivité, ce que la GPAO a souvent du mal à faire : écrans et documents complexes, traitements longs dont le résultat est difficile à reconstituer, difficulté à pénétrer dans l'atelier... De nombreux lecteurs se retrouveront dans ce constat.
A l'inverse, seule la GPAO va nous permettre d'acquérir des données et de les analyser, mesurer la performance d'un atelier, calculer les charges, faire des prévisions d'effectifs...
Le schéma le plus courant est donc de laisser le kanban déclencher les lancements, et de confier à l'atelier la création des Ordres de Fabrication pour l'acquisition des données, l'édition des documents de travail : fiche technique, documents qualité, etc. Cette démarche permet aussi une responsabilisation des opérateurs dans le respect des quantités saisies en production : l'OF est le reflet de « leur » kanban. Il est important d'intégrer les créations d'OF, saisies de production et clôture d'OF, dans la procédure kanban. L'informatique fait alors partie du kanban et s'intègre naturellement dans le quotidien.
Un autre schéma peut aboutir à la suppression de certaines saisies et OF. Prenons l'exemple d'un atelier, ou d'un îlot, réalisant des opérations d'assemblage intégrant des composants achetés et des sous-ensembles que l'îlot assemble au préalable. Dans un fonctionnement de GPAO classique, nous aurions des OF pour le produit livré par cet îlot et des OF pour le
s sous-ensembl es, avec une gestion des stocks pour ces derniers. Donc un ordonnancement et des saisies contraignants.
Nous pourrions envisager de supprimer les OF sur les sous-ensembles et la gestion des stocks qui va avec, avec un kanban permettant une gestion directe par les opérateurs. Les déclarations de production pourraient être effectuées uniquement sur le produit sortant de l'atelier.
Il n'y a donc pas de recette universelle. Cependant, le kanban amènera, dans tous les cas, une simplification dans l'exploitation de la GPAO et sera souvent un moyen efficace de fiabiliser les saisies de production et les mouvements de stock.
Que devient la GPAO dans les décisions de lancement ?
Dans la mesure où le produit est géré en kanban, les outils tels que le Calcul des Besoins Nets, ou l'Etat des Manquants, ne doivent plus être utilisés pour les lancements, sinon, nous entrons dans la plus totale confusion.
Par contre, le CBN en particulier, reste opérationnel pour communiquer sur des besoins à moyen terme. Ces informations sont évidemment fondamentales dans la relation avec les fournisseurs pour lesquels on va demander progressivement une réduction des lots livrés et des délais (kanban « approvisionnements »). Nous retrouvons là la notion de moyen terme pour la GPAO et de court terme pour le kanban.
Dans la mesure où cette information est disponible dans la GPAO, affecter aux produits un « Gestionnaire Kanban », ou une « famille kanban » permet d'isoler ces produits dans le CBN.
Modules kanban dans les GPAO et ERP
D'une manière générale, nous pouvons constater que les éditeurs ont eu l'approche suivante quant à l'intégration du kanban dans leur GPAO :
. Rien, et c'est souvent bien...
. La simple possibilité d'éditer des étiquettes (sans calcul !) en qualifiant les articles « géré en kanban »
. L'impossibilité de créer un OF pour les articles « géré en kanban »
. L'élimination de ces articles dans le CBN
. Etc.
Peu de progiciels intègrent le calcul des étiquettes et celui-ci n'est pas toujours satisfaisant. Il y a heureusement des exceptions, mais on ne choisira pas son ERP sur ce seul critère...
Concrètement, a-t-on réellement besoin d'une intégration ? Nous avons vu qu'il nous faut un calcul de la Consommation Moyenne Journalière, qu'il nous faut isoler ces produits dans le CBN et que pour le reste, ces produits restent normaux ! Gardons notre bon sens et n'inventons pas des contraintes informatiques pour une démarche qui se veut proche du terrain et des opérateurs et dont les résultats sont spectaculaires. Même si c'est parfois difficile, essayons de faire simple...
-------------------------------------------------------------------------------------------------------
Pour vos remarques, vos questions sur cet article, contactez :
Daniel CHABBERT
Pôle Productique Rhône-Alpes
04 77 91 11 30
Chabbert@ppra.fr
Yves LECOCQ Cabinet BELIER ASSOCIES y.lecocq@belierassocies.fr
04.78.35.65.25 http://www.belierassocies.fr
|
