L’un des écueils de la mise en place du digital en usine, c’est de passer son temps à faire des essais sans jamais transformer. Certains parlent même de « l’enfer des POC » (Proof of Concept) pour qualifier le désarroi des directions générales qui ont l’impression de dépenses des sommes conséquentes pour investir sur l’avenir, sans obtenir le retour qu’elles seraient en droit d’en attendre.
Cette situation s’inscrit dans les problèmes de « legacy » des systèmes IT dans l’industrie. Les systèmes IT dans les années 1980 ont été conçus avec un objectif de robustesse avant toute chose. Il s’agissait de simplifier, d’automatiser et de sécuriser des flux éminemment complexes de matière et d’information, depuis le développement de nouveaux produits avec toute la diversité de leurs nomenclatures jusqu’à la prise de commande effective et à l’exécution des ordres de fabrication sur le terrain. Demander à ces mêmes systèmes de devenir agiles paraît antinomique avec ce qui était leur mission de base. Cependant, pour réagir à l’apparition des géants du digital, le monde des usines a commencé à bouger, avec l’espoir d’obtenir des gains de productivité. Mais la peur de déstabiliser le sacro-saint « système » cause de nombreuses difficultés. Tétanisé par la lourdeur du système, le management incite les équipes de terrain à se lancer dans des initiatives locales, qui sont souvent couronnées de beaux succès. Mais elles ne passent jamais à l’échelle, car elles ont été réalisées « hors » système et ne peuvent donc pas être rattachées à l’architecture en place. Cette impasse est amplifiée par les relatons souvent distantes entre la direction des systèmes d’information (DSI) et la direction des opérations.
Le DSI, acteur « expert », est essentiellement focalisé sur son architecture IT très complexe. Il est en relation permanente avec des « éditeurs » ou « intégrateurs » et considère avoir pour mission principale de maintenir la continuité opérationnelle de l’ensemble, grâce à ces prestataires coûteux mais fiables. Comme, en plus, certains fondamentaux de l’informatique agile manquent à l’usine – pas de Wifi, pas de cybersécurité ou pas de SSO (Single Sign-On) – notre DSI finit par se désintéresser complètement de ce qu’il pourrait apporter à la création de valeur opérationnelle et à la génération d’usage par les équipes de terrain.
De son côté, le COO (Chief Operating Officer) est tout entier absorbé par la recherche de gains de productivité. Mais après trente ans de dogme sur la « sacralité » du système informatique, il n’imagine même pas pouvoir en challenger la structure ou simplement accéder de façon simple aux milliards de données qui sont générées par son process industriel et par ses équipes au quotidien.
Peur de déstabiliser le système, absence d’appropriation des données du système, crainte de trahir une lettre de mission vieille de trente ans, dé-focalisation du « business » et de l’usage, peur que les équipes passent du temps à « jouer » avec les nouveaux outils, et manque de confiance dans la création de valeur que pourrait apporter le changement… tout pousse à l’immobilisme, ou en tout cas ralentit, voire empêche, le déploiement du POC à d’autres zones.
Pour éviter ce type de problème, il faut intégrer dès le départ une notion de continuité d’usage, en réfléchissant à la solution de terrain non pas comme un bloc indépendant, mais comme un ensemble qui permet de remonter de la donnée et de structurer cette donnée de façon cohérente, d’une façon nouvelle et standardisée. Ici, le parallèle avec la méthode de transformation opérationnelle est très précieux : lorsqu’un nouvel standard est créé dans un système industriel peu mature, la bonne pratique consiste à créer dès le départ la première brique du système de production à partir de ce standard, et donc de réfléchir de bas en haut. Cette gymnastique conduit petit à petit, de façon systémique, à créer le système de production dans son ensemble. Par exemple, dans un système industriel qui comprend plusieurs usines qui font de l’usinage avec des machines similaires éparpillées sur plusieurs sites, lorsqu’un premier standard de changement de série est défini par les équipes, il est important de penser aussitôt à la formalisation et au partage qui en sera fait avec les autres usines. Mettre en place un outil digital se fait de la même façon. Dès le départ, et après avoir validé l’usage, il est important de se demander où et comment la donnée sera stockée, avec toutes les questions de gouvernance associées à cette donnée. En termes de connexion ensuite, deux options sont possibles : soit venir se connecter sur les systèmes existants, dans l’architecture existante, soit lancer la création d’une première brique de ce qui sera le data lake (ou lac de données) futur, en décidant de passer les nouvelles données générées en « maîtresses » et donc d’avoir des systèmes asservis à ces données.
L’avantage de la première solution, c’est de faire rapidement la jonction avec ce qui est déjà en place et donc de peu perturber les pratiques existantes au sein de la DSI. En revanche, elle présente deux inconvénients : d’une part, il est en général assez compliqué de se connecter à l’existant, d’autre part, cela n’amène par à transformer en profondeur l’architecture IT. Or, à l’instar du standard de changement de série qui représente une bonne occasion de créer une brique du système de production, la mise en place d’une solution digitale est une bonne opportunité pour revoir l’architecture existante, ou la créer si elle n’existe pas encore.