4
Du Kanban au Concurrent Engineering On présente souvent, et Marc Henry vient de le rappeler dans son article « Coût, qualité et Cals / C.E. dans les programmes d'armement », l'introduction du concept de flux tendu dans l'industrie manufacturière et celle de sa version japonaise plus spécifique, le Kanban, comme l'une des premières manifestations avant la lettre de ce qui, généralisé quelques dizaines d'années plus tard sur les deux rives du Pacifique, allait être appelé Concurrent Engineering. et la source des progrès considérables de l'organisation industrielle et de la maîtrise d'ouvrage en cette fin de siècle. Dans une définition il est vrai hâtivement simplifiée mais malheureusement fort répandue, le Concurrent Engineering permettrait de gagner sur les coûts, la qualité et les délais en faisant effectuer l'ensemble des tâches d'un projet en parallèle, évitant ainsi un séquencement coûteux en temps par nature, on le comprend bien, et générateur en outre d'incompréhensions et d'itérations inutiles. Or, le flux tendu est précisément séquentiel. N'y aurait-il pas contradiction ? A moins qu'il ne faille regarder de plus près, et d'un côté et de l'autre... Le flux n'est pas tendu en effet par une réduction imbécile des stocks et des en-cours (car alors, il n'y a plus de flux du tout, les coûts et les délais augmentent, c'est le cas typique des entreprises industrielles traditionnelles en sous-charge ou à cours de trésorerie). La tension du flux sur la production est obtenu par la prise en compte de la demande. On parle aussi de flux tiré par l'aval. Dans le système Kanban, l'information vivante, celle qui doit nécessairement être écrite, (j'ai exécuté telle tâche) est liée à la matière, avec chaînage arrière : je préviens aussi le poste de travail précédent (et peut-être aussi mon chef), mais c'est le poste de travail précédent qui prend immédiatement les

Du kanban au concurrent engineering

Embed Size (px)

Citation preview

Page 1: Du kanban au concurrent engineering

Du Kanban au Concurrent Engineering

On présente souvent, et Marc Henry vient de le rappeler dans son article « Coût, qualité et Cals / C.E. dans les programmes d'armement », l'introduction du concept de flux tendu dans l'industrie manufacturière et celle de sa version japonaise plus spécifique, le Kanban, comme l'une des premières manifestations avant la lettre de ce qui, généralisé quelques dizaines d'années plus tard sur les deux rives du Pacifique, allait être appelé Concurrent Engineering. et la source des progrès considérables de l'organisation industrielle et de la maîtrise d'ouvrage en cette fin de siècle.

Dans une définition il est vrai hâtivement simplifiée mais malheureusement fort répandue, le Concurrent Engineering permettrait de gagner sur les coûts, la qualité et les délais en faisant effectuer l'ensemble des tâches d'un projet en parallèle, évitant ainsi un séquencement coûteux en temps par nature, on le comprend bien, et générateur en outre d'incompréhensions et d'itérations inutiles.

Or, le flux tendu est précisément séquentiel.

N'y aurait-il pas contradiction ? A moins qu'il ne faille regarder de plus près, et d'un côté et de l'autre...

Le flux n'est pas tendu en effet par une réduction imbécile des stocks et des en-cours (car alors, il n'y a plus de flux du tout, les coûts et les délais augmentent, c'est le cas typique des entreprises industrielles traditionnelles en sous-charge ou à cours de trésorerie).

La tension du flux sur la production est obtenu par la prise en compte de la demande. On parle aussi de flux tiré par l'aval. Dans le système Kanban, l'information vivante, celle qui doit nécessairement être écrite, (j'ai exécuté telle tâche) est liée à la matière, avec chaînage arrière : je préviens aussi le poste de travail précédent (et peut-être aussi mon chef), mais c'est le poste de travail précédent qui prend immédiatement les dispositions pour maintenir l'en-cours d'atelier. Ce mécanisme récursif est désormais bien connu.

Le séquencement des tâches de production est donc respecté, et l'on ne saurait dans ce cas être plus taylorien, si l'on ne regarde le cheminement de la production que du point de vue de la matière.

Mais en réalité, le séquencement des tâches organiques dont la grande industrie a pu faire croire le modèle naturel (parce que raisonné) et que l'informatique de première génération, même habillée de temps réel, essaie vainement depuis vingt ans d'automatiser (j'analyse les commandes, je calcule les besoins, je planifie, j'ordonnance, puis enfin je lance chaque tâche une par une ou j'alimente chaque entrée sur la chaîne), ce séquencement a vécu en l'espèce.

Bien sûr cela ne s'est pas fait tout seul, et il existe toujours bien entendu dans l'entreprise une activité de structure.

Mais plus personne n'attend les ordres de son chef pour faire son boulot : on peut dire qu'on est passé, par une maîtrise conjuguée de l'information et de la matière, dans un mode de

Page 2: Du kanban au concurrent engineering

fonctionnement coordonné / décentralisé où le réseau d'ordres est transverse. Dans le jargon des spécialistes, on parlera de processus de production objet, object-oriented production process.

Et c'est alors seulement que l'on obtient, en fonction de l'outil de production, le juste en-cours et le juste délai.

On peut ajouter que la structure ne se désintéresse pas pour autant de la production qu'elle continue à superviser et dont elle fera évoluer les procédures et les moyens autant que de besoin. La structure travaille sur les paramètres d'un processus de production générique en quelque sorte, alors que le maillage du réseau d'ordres transverse permet le pilotage du processus instancié.

On a corrélé ou emboîté un processus de structure, et un processus de production. Chacun des deux processus est piloté par sa finalité (ce qu'il produit, un maillage ou un objet manufacturé) à son rythme spécifique et c'est ainsi que, pour un modèle d'entreprise défini, on a obtenu une meilleure réactivité par rapport aux besoins et à l'état de l'art du moment.

On voit que le maillage (et non pas seulement le découpage) des activités de structure et de production est véritablement la pierre angulaire de ce type d'approche : un processus ne peut pas en effet être ici le simple regroupement de tâches ou d'activités ; son identification répond au contraire à des critères de pertinence essentiels qu'il importe d'étudier avec soin, dont le respect permet des progrès révolutionnaires et dont la méconnaissance conduit... à la catastrophe.

Il ne s'agit pas d'une vue de l'esprit : il est fréquent qu'une entreprise ayant initialisé une démarche de Business Process Re-engineering disparaisse dans la faillite ; mais on peut évidemment toujours soutenir que dans chacun des cas, les causes la faillite étaient antérieures et le Re-engineering, quoique mal articulé, un simple acharnement thérapeutique...

On reconnaît dans les démarches de type Kanban les ingrédients essentiels suivants :

la valorisation structurée et collective de la responsabilité individuelle (empowerment), une modélisation pertinente du fonctionnement de l'entreprise en un maillage de processus d'activité finalisés vers la satisfaction de la demande, prenant définitivement le pas sur les structurations organiques, même matricielles, (le marché pilote la production, non les commerciaux). le respect des rythmes et des cycles propres à chaque processus d'activité, la priorité à la maîtrise vivante de l'information et d'abord celle qui circule avec les flux et qui, constituant le premier réseau d'ordres, donne au pilotage toute sa réactivité (par opposition aux informations des comptes rendus hiérarchiques, perpendiculaires aux flux).

Ce sont de tels modes de fonctionnement, radicalement à l'opposé de ceux qui tentent de ne mettre en avant que de pseudo et très inflationnistes relations clients-fournisseurs (relations peut-être même d'ailleurs purement et simplement paralysantes), que propose de généraliser en effet le concurrent engineering pour les entreprises ayant à conduire des programmes, en insérant dans les cycles de vie la construction du maillage des processus d'activité, en valorisant la responsabilité des acteurs à travers deséquipes intégrées structurées (chacun sait, à son niveau, avec qui il travaille et les bouclages se font plus naturellement) et en facilitant par un environnement de données partagé, la circulation de l'information vivante

Page 3: Du kanban au concurrent engineering

et pertinente, vivante au vu des rythmes de l'entreprise et des programmes, pertinente en fonction des méthodes et des procédés mis en oeuvre et reconnus.

Bureau Cals