Il existe un parallèle parfait entre ce qui permet au système opérationnel lean d’être agile et ce qui permet au système IT de l’être. L’objectif recherché est similaire : il s’agit de créer de la valeur par le bas dans l’ensemble de l’entreprise. Dans le système lean, la méthodologie qui permet d’atteindre cet objectif s’appelle le Kaizen ou amélioration continue. L’idée est de solliciter chaque membre des équipes, chaque jour, pour faire une petite amélioration. C’est la méthode des petits pas qui créé des transformations conséquentes grâce à la rapidité d’exécution : si chaque cerveau de l’entreprise est sollicité et considère que son travail consiste à la fois à exécuter des tâches et à améliorer la façon de le faire, le système progresse de façon exponentielle. Et c’est ce qui a conduit Toyota à devenir l’un des constructeurs les plus puissants au monde en quelques décennies et sans croissance externe.
De la même manière, l’amélioration par le digital est beaucoup plus rapide et pérenne, si elle est exécutée par le bas, avec l’ensemble des équipes. La méthode utilisée est celle du « test&learn » qui conduit au développement continu.
Pour que ces deux méthodes de terrain fonctionnent, il faut néanmoins capitaliser sur les améliorations de terrain. Beaucoup de groupes butent en effet aujourd’hui sur « l’enfer des POC » : les équipes lancent toutes sortes d’initiatives sur le terrain, mais il n’a a aucun mécanisme qui permet ensuite de centraliser les efforts pour redistribuer, partager et homogénéiser le système dans son ensemble.
La clé pour éviter cette dérive, c’est d’utiliser la même approche pour la partie IT que celle qui a été utilisée pendant des années pour la partie « Opérations », à savoir capitaliser dans le système de production via des standards. Dans la sphère IT, la capitalisation se fait grâce au design qui permet de créer des applicatifs adaptés à l’usage souhaité et aux Persona qui ont été définis pendant la phase de test&learn.
Enfin, la couche supérieure comporte l’architecture du système qui est alimentée par des règles venant du système de production côté opérations, et par des standards d’interconnexion côté architecture IT (ou API). Par exemple, dans une usine de fabrication de sacs à main, le système de production précisera que les flux sont tirés depuis le client jusqu’à la ligne de découpe de la matière, et poussés par un système de production par lot en aval. Cette description correspond à un morceau de l’architecture des flux de l’usine. Celle-ci s’appuie sur un système de production qui définit : comme chaque ordre de production est lancé dans chacun des deux environnements précités, quelles règles de flux s’appliquent au pied de chaque machine (par exemple le FIFO), quels standards de fabrication chaque métier doit utiliser (par exemple les piqueuses), quelles routines de management doivent être exécutées et quand (tour de terrain, revue de performance…). L’ensemble permet à la matière de se transformer, avec un protocole préétabli.
De la même façon, l’architecture IT définit quels systèmes permettent de prendre les commandes des clients, comment ces commandes sont ensuite transformées en ordre de fabrication et avec quel système et comment ces deux ensembles s’interfacent avec les autres systèmes qui donnent les informations de base pour fabriquer : plans de pièces, nomenclatures, gammes, approvisionnement des matières premières, gestion des stocks, etc. Cette cartographie complexe représente l’architecture IT. Elle s’appuie sur un ensemble d’applicatifs de terrain, et permet de faire circuler les données en fonction de l’usage qui doit en être fait par les équipes de terrain. La donnée se transforme, tout comme la matière se transforme. Et pour que l’ensemble puisse fonctionner de façon cohérente, il faut avoir établi des protocoles d’échange standardisés, appelés API. Dans le cas des sacs à main, une API permet d’aller chercher les plans du sac définis par l’équipe de création, la nomenclature et les gammes mises au point par l’équipe d’industrialisation, et de connecter ces données à l’ERP pour lancer un ordre de fabrication complet, en donnant toutes les informations à l’équipe de production. Les API servent à la fois à aller chercher de la donnée dans un sens (pouvoir produire) mais aussi à la remonter dans l’autre sens (donnée de résultat sur le niveau de qualité, le volume produit, le taux d’adhérence au planning…). Dans de nombreux environnements de fabrication, un système de terrain permet cette remontée inverse, le MES (Manufacturing Execution System). Ce système fonctionne en temps réel et agrège un certain nombre d’applicatifs de terrain (qualité, planning, production, maintenance), afin d’intégrer les données sous un même chapeau.