Transcription

• Speaker #0

  Salut à tous et bienvenue dans Oser l'Efficacité. Moi, c'est Perrine Thiebaud, passionnée d'optimisation et de performance depuis plus de 10 ans et fondatrice de Digitik. J'en ai marre de voir des processus qui patinent, des pertes de temps récurrentes, des empilements d'outils irréfléchis. On met des pansements partout, alors qu'un check-up général serait plus que nécessaire. Dans ce podcast, je partage avec vous mes outils, méthodes et analyses pour simplifier, améliorer et booster vos performances. Seul ou avec mes invités ? On explore comment rendre vos processus plus efficaces et adaptés à vos besoins. Et quand la base est bien saine, on parle aussi d'outils numériques. Alors, et à oser l'efficacité et à vraiment faire la différence, c'est parti ! Dans l'épisode du jour, on retrouve Dominique Wieser et si vous ne l'avez pas encore écouté, je vous invite à aller écouter l'épisode de la semaine dernière où il nous parle du métier d'auditeur de ligne et de pourquoi auditer sa ligne. Mais cette semaine, on va creuser un autre sujet qu'il a occupé pendant 25 ans de sa carrière. A l'aube des années 90, Dominique Wieser rejoint une usine de pâte à papier pour réaliser un projet de transformation de l'usine pour qu'elle puisse à l'avenir également produire du papier journal. A l'époque, c'était un projet assez stratégique, même si on sait qu'aujourd'hui, le papier journal, ça n'a plus tout à fait le vent en poupe. Pendant sa carrière, il a participé à pas moins de deux implémentations de logiciels de gestion de la maintenance assistée par ordinateur. Et c'est ça que je veux creuser aujourd'hui, parce que clairement, le contexte du numérique dans les années 90, c'est pas du tout celui d'aujourd'hui. Et ça nous fait vraiment réfléchir à la chance qu'on a. Je vous laisse sur ces mots et place à l'épisode. Bonjour Dominique.

• Speaker #1

  Bonjour Périne.

• Speaker #0

  Aujourd'hui, je voudrais qu'on parle de ta plus longue expérience pro chez Stracell. Est-ce que tu peux nous parler un peu du contexte de ta prise de poste dans cette usine et ce pourquoi tu l'as rejoint au départ ?

• Speaker #1

  J'ai démarré ma carrière diplôme en poche, diplôme Bac plus 2 dans l'électrotechnique. Diplôme en poche, j'ai d'abord voulu apprendre le métier. J'ai passé trois ans dans une société de prestations de services électrotechniques qui m'a fait découvrir pas mal d'industries différentes, que ce soit de l'industrie chimique, l'industrie agroalimentaire. Alors... Tout ça basé globalement dans le nord de l'Alsace. Ça m'a permis un petit peu de voir tout ce que nos clients fabriquaient, comment c'était fabriqué et ça m'a permis d'apprendre le métier. Ensuite, Stracell, la société dans laquelle j'ai travaillé pendant 23 à 25 ans, a été rachetée par un groupe finlandais qui prévoyait d'installer une nouvelle machine à papier. Quand on parle de machine à papier, ce n'est pas un photocopieur, c'est bien plus gros que ça, c'est vraiment une usine, c'est de l'industrie lourde, à feu continu. Et le projet à l'époque qui valait, en euros d'aujourd'hui, 300 millions d'euros, était considéré comme le plus gros projet industriel de la décennie. Que ce soit en génie civil, en électrotechnique, en instrumentation, en informatique, c'était un très gros projet. Donc un projet très intéressant. J'étais très au courant de ce que ce projet allait faire et une offre d'emploi. Pour un assistant chef de projet électrotechnique a été publié. J'ai postulé et j'y suis allé pour... essentiellement faire ce projet pendant un an, un an et demi, le temps de construire cette machine, cette usine plutôt, et de démarrer cette usine. À la fin du projet, le chef de projet a été nommé responsable de maintenance électrotechnique du site. Il m'a proposé un poste de superviseur de maintenance, à encadrer les techniciens avec lesquels on avait travaillé pour mettre en route cette usine. Poste que j'ai accepté, car entre-temps, j'ai découvert ce que c'était que de travailler pour un groupe international. Je n'avais pas dit, mais le racheteur... de Strassel était un groupe finlandais et j'ai eu la grande chance de faire un projet pendant un an et demi qui s'est passé totalement en anglais, ce qui m'a permis, entre autres, de passer d'un niveau d'anglais très scolaire à un niveau d'anglais qui me sert beaucoup aujourd'hui.

• Speaker #0

  La meilleure des écoles. Du coup, post-projet, tu deviens superviseur de maintenance. C'est quoi les premiers défis que tu rencontres pour la gestion de la maintenance ? C'est un métier qui est nouveau pour toi à ce moment-là.

• Speaker #1

  Alors en effet, c'est un métier qui est totalement nouveau. Et le premier souci que je rencontre, c'est que la machine tombe en panne, l'outil de production s'arrête, et je n'ai, comme l'usine est tout à fait neuve, je n'ai aucun historique, aucune connaissance, je ne sais pas d'où peuvent venir les problèmes. On n'a ni historique d'incidents qui se sont passés avant, vu que c'est tout neuf, et on n'a pas de données numériques enregistrées qui nous permettent a posteriori d'analyser ce qui s'est passé sur la machine. Donc on est totalement nu devant ces phénomènes-là. Donc très compliqué. J'ai ressenti une certaine frustration du fait que l'usine avait démarré, un certain nombre de prestataires sont restés sur cette machine pendant 3, 4, 5, 6 mois pour nous aider, pour nous former, mais assez vite ces personnes ont disparu du site et on a été confronté à des difficultés parce qu'on n'avait à peu près aucun outil numérique, aucun outil, après on verra que numérique c'est bien. On n'avait aucun outil de collecte de données, d'enregistrement qui nous permettait de nous baser sur ce qui s'est passé dans le passé pour voir un petit peu. par où il fallait commencer pour essayer de dépanner. Gros défi. Ok.

• Speaker #0

  Parce que là, on a quand même bien replacé le contexte. On est dans les années 90. Un logiciel, ça se démarre sous disquette à l'époque. Un ordinateur, tout le monde n'en a pas un à la maison, loin de là. À partir de quand tu te dis que le numérique est potentiellement une voie intéressante pour justement garder des données, les réutiliser toujours ? C'est la première idée qui te vient en tête pour que tu ne te retrouves pas dans la même situation. à partir du moment où la machine aura tourné un certain temps, ou tu envisages d'autres choses avant et le numérique vient dans un second temps ? Ça se passe comment ?

• Speaker #1

  Début des années 90, l'automatisation était déjà passée par là. Beaucoup d'usines, beaucoup de lignes ont déjà été modifiées, d'anciens systèmes électro-techniques vers des systèmes avec des automates programmables. Donc, ce n'était quand même pas la préhistoire, même si ça remonte maintenant à 40 ans presque. Doucement, doucement. Pardon ? Doucement. Doucement, oui, 35 ans. Ça remonte maintenant à 35 ans. Il existait déjà des solutions d'acquisition de données, mais la donnée à collecter était excessivement chère. Bien sûr, on pouvait déjà communiquer avec les machines pour en extraire des données, mais les logiciels n'étaient pas développés et en tout cas pas simples ni faciles d'accès. Mon souci principal était qu'à chaque fois qu'il arrivait une panne dans l'usine, on mettait en place des enregistreurs. Alors au début, c'était des enregistreurs papier qui tournaient, qui défilaient du papier à longueur de journée. Et on espérait que quand le problème allait se reproduire, qu'on pouvait enregistrer les données et voir quelles données avaient bougé en premier pour essayer de comprendre quelle était l'origine du problème. Bien sûr, le problème ne revenait pas dans les heures ni dans les semaines qui suivaient. Donc on avait d'autres soucis, donc on réaffectait ces enregistreurs à d'autres événements. Et en fait, on ne trouvait jamais rien. Dans les années 90, des produits... Je n'allais pas dire grand public, mais des produits assez intéressants sont apparus et on m'a donné les moyens parce que c'est un des points clés. Il faut avoir les moyens d'investir dans cette acquisition de données qui à l'époque était excessivement chère. Mais nous avons commencé à enregistrer systématiquement les données les plus importantes qui pouvaient nous donner des informations sur les causes éventuellement des pannes. Ce qui permettait, post-panne, La panne est arrivée dans la nuit. Le lendemain matin, on prenait nos ordinateurs, même si c'était des ordinateurs pas très rapides, mais ça nous permettait d'aller consulter l'historique et de commencer tout doucement à construire une stratégie de quelles sont nos données qui nous manquaient pour les enregistrer, pour faire de l'acquisition et ensuite de traiter l'information. Et ça, ça nous a beaucoup aidé.

• Speaker #0

  Donc à ce moment-là, vous avez déjà au moins un ordinateur au bureau qui est accessible pour tout le monde pour faire ses saisies ?

• Speaker #1

  Technologiquement, on n'était pas en retard. Ok. On a démarré dans les années 90, on n'avait pas un ordinateur par personne, mais très rapidement, chaque superviseur d'équipe avait un ordinateur. Nos techniciens n'étaient pas tous dotés d'un ordinateur, mais avant 1995, l'ensemble des techniciens a été doté d'un PC. De manière à, et là on va y arriver, d'implémenter notre stratégie de GMAO. Si vous voulez faire de la GMAO, si vous voulez demander aux opérateurs de saisir des incidents et des rapports d'incidents, il faut qu'ils aient... systématiquement accès à un outil qui leur permette de saisir ça.

• Speaker #0

  Du coup tu parlais d'enregistrer les données, ça c'était avant GMAO, ça veut dire quoi enregistrer au départ ?

• Speaker #1

  Alors il y a deux besoins, j'avais deux besoins. Le premier besoin c'était les mesures industrielles, des mesures de vitesse, de température, de pression, qui nous permettent de comprendre pourquoi le process a mal fonctionné ou s'est arrêté de fonctionner. Donc ça c'est de l'enregistrement automatique de valeurs et de données industrielles. De l'autre côté, on a besoin aussi de données factuelles de ce qui s'est passé. Il y a eu une panne, le technicien a dépanné, le technicien va vous dire, voilà, il s'est passé ça, j'ai fait ça pour résoudre tel problème. N'ayant pas de GMAO, ou du moins ne renseignant pas la GMAO avec ces événements-là, quand il arrivait quelque chose, on ne pouvait pas se remettre sur ce code objet ou sur cette machine pour savoir que s'est-il passé avant, est-ce que j'ai déjà eu ce problème, est-ce que ça peut m'aider à trouver la solution. J'avais deux soucis principaux, c'est qu'on ne collectait pas les données industrielles, les données de production, les données de qualité, pour nous permettre d'avoir un historique de variation et des raisons des stops. Et de l'autre côté, je n'avais pas d'historique de ce qui s'était passé pour nous aider à dépanner plus vite. Tout début 90, le projet de GMAO était déjà en cours avant que le rachat du groupe finlandais ne s'était fait. Le projet de GMAO n'a pas démarré avec la nouvelle usine, mais c'était déjà quelque chose qui était en cours. Mais les seuls points qui ont été implémentés, c'était essentiellement la gestion du magasin avec les entrées-sorties magasins, des pièces nécessaires pour faire les différents travaux. Donc on travaillait à l'époque avec des OTs, des ordres de travail, sur lesquels on pointait les heures. ont pointé le matériel nécessaire, le magasin en était bien sûr informé et les achats ont été développés en même temps, de manière à ce que toute la partie achat, stockage et utilisation du matériel soit fonctionnelle. C'était le but premier de cette GMAO et ça, ça a fonctionné quand même relativement vite.

• Speaker #0

  Donc pour résumer, quand tu rejoins l'usine, il y a un outil de GMAO mais sur une vision assez financière de la maintenance, de savoir ce qui a été consommé entre sorties et des gens qui ont passé du temps. Oui. La maintenance en tant que telle sur le terrain n'est pas implémentée, mais quelque part l'outil existe et il n'y a que, je mets des guillemets, mais il n'y a que à pousser les process pour qu'on puisse l'intégrer à ce logiciel et faire tout fonctionner ensemble. Ou il y a une refonte complète du logiciel à prévoir et c'est pas...

• Speaker #1

  Alors absolument pas. Ce logiciel était prévu et dans mon approche de la GMO, j'ai eu deux hasards qui m'ont beaucoup aidé. Le premier hasard était, et j'ai presque découvert par hasard... le fait que le rapport d'incident était une fonctionnalité intégrée dans la GMAO. Donc du jour au lendemain, je découvre qu'il suffit de montrer au technicien de trouver le code objet ou le numéro de la machine sur laquelle il a travaillé pour que le soir, avant de quitter le lieu ou après son intervention, qu'il aille sur son ordinateur et qu'il dise sur cette machine, il m'est arrivé ça, j'ai fait ça, ça a résolu ça, pour plus que ça arrive, il faudrait faire ça. Donc j'ai demandé aux techniciens de mon équipe de systématiquement, quelles que soient les opérations qu'ils fassent dans la journée, de faire des rapports d'incidents.

• Speaker #0

  Ça fait plus de boulot ça, non ?

• Speaker #1

  Ah ça fait plus de boulot ! Et ça oblige le technicien à se dévoiler quand même un petit peu. Ça a complètement changé bien sûr le rapport entre deux portes. Je te dis ce qui s'est passé aujourd'hui, on n'a rien écrit, j'ai compris à moitié, j'ai pas bien expliqué, j'en déduis pas forcément les bonnes conclusions. On passe de ça à j'ai écrit quelque chose et si le lendemain ou le surlendemain, je veux relire ce qui s'est passé, je me dis c'est très bien, j'ai compris. Ou alors sur ce que tu m'as écrit là, je n'ai rien compris, donc on en reparle. Ça a démarré, surtout dans mon équipe. Ça a été compliqué parce que ce n'était pas la culture des techniciens. J'avais la chance que la majorité des techniciens de l'équipe étaient nouveaux et on avançait ensemble. Par contre, la réticence des anciens... de la boîte qui n'avait depuis 10, 15 ans, 20 ans, pas eu l'habitude d'écrire une seule fois leur compte rendu d'activité, c'était plus compliqué. Mais voyant que ça fonctionne, voyant que le fait d'écrire ces rapports d'incidents fonctionnait, qu'on pouvait aller analyser à posteriori, c'est devenu dans le service, parce que je n'étais pas le seul superviseur de maintenance, on était quatre superviseurs de maintenance à se répartir les différents secteurs de l'usine, c'est devenu une obligation de travailler de cette façon-là. Je ne me suis pas fait que des copains à cette époque, mais c'est comme ça.

• Speaker #0

  C'est ce que tu disais, au départ c'est perçu comme ça fait plus de boulot, et puis finalement quand ils envoient la valeur, tout le monde s'y est mis un peu, un petit peu chacun à son rythme, mais au final la valeur elle est perceptible pour tout le monde. C'est ce que je répète assez régulièrement, quand on veut mettre en place un accompagnement numérique, il faut avant tout que ce que tu vas mettre en place ait de la valeur pour les gens qui l'utilisent. Parce que si c'est juste pour mettre... Un logiciel en place de faire rentrer des données à des gens mais qu'ils n'ont jamais de retour sur les données qu'ils notent, il y a très peu de chances que ce soit fait, ou même fait correctement si c'est fait.

• Speaker #1

  Alors tout à fait, il faut bien montrer à ceux à qui tu demandes un effort supplémentaire que ça va leur servir. Malheureusement, ça ne va pas leur servir au bout de deux mois, trois mois. C'est deux ans, trois ans plus tard, quand on aura acquis suffisamment de données, suffisamment d'expérience. Qu'il suffit simplement à la machine de demander, tiens, que s'est-il passé sur cette machine ? Et ah tiens, ça ressemble beaucoup à ce que j'ai maintenant, qui permet de dépanner plus vite. C'est pas simple à faire adhérer tout le monde. Et d'ailleurs, je dois être franc, tout le monde n'y a pas adhéré. Certains sont partis à leur traite en n'ayant pas adhéré du tout au projet.

• Speaker #0

  En n'ayant pas saisi une ligne dans le logiciel, jamais. Jamais.

• Speaker #1

  Voilà.

• Speaker #0

  Et qu'est-ce qu'on fait dans ces cas-là pour les gens qui ne veulent pas du tout saisir ? On fait à leur place ou on laisse faire ?

• Speaker #1

  Alors à l'époque, j'étais un peu égoïste dans l'équipe. J'ai réussi à faire adhérer tout le monde. Donc c'était d'une bonne chose. D'autres techniciens qui ne se servaient pas trop. ou qui ne voyaient pas l'utilité de systématiquement écrire ce qu'ils faisaient, quand ils ont rejoint l'équipe un peu après, parce que comme dans toute bonne société moderne qui se respecte, il y a des réductions du nombre de personnels. Donc des postes de responsables, de superviseurs de maintenance, ont été réduits de 4 à 2. Donc certains techniciens ont rejoint mon équipe. Tous n'étaient pas satisfaits de devoir rejoindre une équipe dans laquelle il fallait travailler un peu différemment. J'ai un exemple d'un collègue qui, effectivement, quand il est revenu, il a dit Oh là là, avec lui, ça va être compliqué de travailler Il a quand même travaillé, il a fait des efforts pour aller dans ce sens-là. La satisfaction est venue sur un moment de 10 secondes, deux ans après, où cette personne a pu me dire Ah, là, cette machine, on pourrait la remplacer parce que regarde toutes les heures que j'ai passées là-dessus. Cette machine, on pourrait la remplacer par une machine beaucoup plus moderne qui nous prendrait beaucoup moins de temps. Dans le système, tout ce qu'il a fait, quand on a pu voir les heures passer, les pièces consommées, et le fait d'utiliser la GMAO telle qu'elle était conçue, ont permis, au bout de 2-3 ans, de montrer que cette machine était chronophage, qu'elle était coûteuse, et qu'il fallait la remplacer par une autre machine. Mais l'avantage, c'est que c'est lui qui est venu en me disant, grâce à son travail, il réussit à prouver ça. Je ne demandais pas plus. Donc voilà. Petite fierté personnelle, mais ça a marché.

• Speaker #0

  C'est clair. Je comprends. Quand les gens s'approprient l'outil et en deviennent sponsors en disant c'est génial et je trouve des choses c'est là où c'est super, parce qu'après, quand on est sur des outils qui se développent, ils deviennent les premiers forces de proposition de ce qu'on peut ajouter. Je vais revenir un petit peu sur le contexte, parce qu'on en a un peu discuté en off de ça. Préparer un projet numérique, à l'époque, on n'est pas sur les ordinateurs les plus rapides, on n'a pas encore un Excel. qui nous permet de préparer des données, de faire des listes, de faire du nettoyage. Comment ça se passe à l'époque ?

• Speaker #1

  Alors ça se passe par un investissement personnel assez conséquent, du fait que l'implémentation de cette GMAO en 1990, c'est deux personnes qu'on alimentait par des listes de matériel pour qu'elles créent l'arborescence des nomenclatures, ce qui veut dire, grosso modo, mettre sous forme de nomenclature cette... l'ensemble des machines de l'usine. L'ensemble des machines de l'usine, une usine de ce style-là, ça représente des milliers de moteurs, des dizaines de milliers de capteurs, donc c'est vraiment un très gros process. Et effectivement, le projet tel qu'il était prévu, c'était deux personnes pendant deux ans à faire de la saisie manuelle de tout ce qu'on leur donnait.

• Speaker #0

  En tant que boulot à plein temps ?

• Speaker #1

  En tant que boulot à plein temps. Ça faisait partie du projet, c'était des équipes. C'était deux personnes mises en place par le prestataire et voilà. Donc on s'est vite rendu compte que... Deux personnes pendant deux ans qui, en fait, ne faisaient que taper dans l'outil par des écrans d'interface de saisie, saisissaient les codes objets, les descriptions, les familles auxquelles ça appartenait, le lien avec la pièce magasin si elle existait. Tout ça, c'était fait à la main.

• Speaker #0

  Ça fait envie.

• Speaker #1

  Ça fait envie et surtout, on s'est rendu compte que la partie électrotechnique que je supervisais, c'était des dizaines de milliers de codes et de liens vers des pièces magasins à créer et qu'on n'y arriverait jamais comme ça. Et par le plus heureux des hasards, et c'est le deuxième hasard, a fait que, au détour d'une machine à café, en prenant un café avec un informaticien, je lui disais que je passais un temps fou, que ça n'avançait pas, qu'on n'arrivait pas à faire rentrer les données. Et il m'a dit, mais tu fais ça sur quoi ? J'ai un tableau Excel où j'ai le code objet, sa description, où il devait rattacher vers le niveau N plus 1, vers où il devait rattacher par le niveau N moins 1 ou à une pièce magasin. Il m'a dit tu me mets ça sous format Excel et moi je fais un transfert dans la... Pour moi l'informatique de 90 c'était pas pensable. Du jour au lendemain, on a fait nos listes de matériel sur Excel, on les a vérifiées, on les a transmises au service informatique qui, sur un petit script, nous a rempli en moins d'une seconde l'ensemble des données qu'on voulait. Ça a mis du temps, 2-3 ans, mais on a eu au bout de 2-3 ans la totalité de nos équipements électriques que nous supervisions. Ces éléments étaient dans la GMAO, donc on a pu faire des rapports d'incident directement au plus proche de l'équipement et ça nous permettait d'avoir un lien vers l'ensemble des pièces du magasin. Ça nous a permis de définir aussi toutes les pièces critiques de la ligne qui n'avaient pas de lien magasin, c'est-à-dire que si elles tombaient en panne, nous n'avons pas la pièce de rechange. Et ça nous a permis d'étoffer le magasin avec tout le matériel nécessaire, dans la limite de la valeur des pièces et des moyens qu'on avait.

• Speaker #0

  Tu parlais des deux personnes qui saisissent les pièces. Au moment où tu te retrouves à le faire un peu seul, c'est la fin de mission de ces deux personnes ? C'est ce que tu m'avais dit.

• Speaker #1

  C'était après leur mission déjà.

• Speaker #0

  Elles ne sont pas gardées parce que le projet est fini. Pourtant, le besoin de saisir des pièces, il est toujours là. Sauf qu'il n'y a plus de personnes à plein temps pour le faire.

• Speaker #1

  Voilà. Alors, le besoin vu de la direction, les machines principales, surtout les machines mécaniques, les grosses machines qui coûtent très cher, tout ça, c'était fait. Mais on n'est pas allé, de mon avis, on n'est pas allé dans le détail de l'ensemble du matériel. Aujourd'hui, je veux dire, on est peut-être allé un peu trop loin, on a peut-être mis des choses qui n'étaient pas utiles, mais au bout d'un moment, c'était tellement simple de faire des copiés-collés parce que beaucoup de machines se ressemblaient qu'on se disait, autant les avoir numérisées quelque part.

• Speaker #0

  Tu as tout mis, du coup, au quotidien, tu peux exactement pointer sur la machine, la pièce dont tu as besoin. Tout à fait. Et l'information, tu l'as. Peut-être qu'elle ne sera pas utile, mais en tout cas, elle est là et tu ne vas pas la rater, en tout cas.

• Speaker #1

  On ne va pas la rater.

• Speaker #0

  Ça marche. Tu m'en as déjà un peu parlé, mais une fois que la GMAO est en place, que c'est fini, que t'es passé à ça, les premières satisfactions qui arrivent, tu nous en as parlé d'une qui est arrivée assez tard finalement, mais est-ce qu'il y a quand même des satisfactions qui arrivent assez immédiatement, où tout a forcément pris du temps jusqu'à ce qu'une panne se reproduise et qu'on puisse se servir des données ? Il y a des choses plus immédiates quand même.

• Speaker #1

  Alors, des industries lourdes comme cette papeterie dans laquelle j'ai travaillé, c'est du temps long, forcément. J'ai un chiffre qui me revient, on avait déjà à l'époque l'habitude de saucissonner nos journées en 1440 minutes, parce que 24 heures de 60 minutes, ça fait 1440 minutes, et en fait chaque jour était décortiqué en X minutes de production, X minutes de panne par manque de matière première, X minutes de panne du fait d'un souci mécanique, X minutes de panne du fait d'un problème électrotechnique. Donc on connaissait exactement notre TRS, on le connaissait bien, taux de rentement synthétique. pour ceux qui n'auraient pas suivi l'épisode suivant.

• Speaker #0

  Pour les autres, je vous ramène aussi à l'épisode 2, il me semble, de la chaîne où on décortique complètement le TRS. Je vous mettrai le lien en description. Vas-y, continue.

• Speaker #1

  Donc, le TRS, nous ne l'appelions pas comme ça à l'époque. Aujourd'hui, on appelle ça le TRS. Donc, on connaissait nos performances et je connaissais les performances de mon équipe. Et nous étions à près de 8 à 9 d'arrêt de production du fait d'un problème électrotechnique dans la première année. où nous avons produit une fois que la machine avait démarré. Le fait d'avoir une GMAO, d'y inscrire tous les incidents, de les analyser, de savoir ce qui s'est passé, de se dire, c'est arrivé une fois, on analyse, qu'est-ce qu'il faut faire pour que ça n'arrive plus ? De mettre en place des plans de maintenance préventive qui n'étaient pas gérés par cette GMAO, parce que je crois, ça fait un moment, que l'outil de gestion de maintenance préventive n'était pas implémenté, en tout cas, on ne l'avait pas démarré. Le fait de mettre en place des systèmes d'acquisition de données avec les années de plus en plus performants ont permis de résoudre ce taux de panne de 8-9% du fait de la technologie électrotechnique. Nous l'avons réduite en 10 ans, donc je parle effectivement de temps long, à 3%. Donc une amélioration de 5 à 6%, c'est énorme. Oui,

• Speaker #0

  c'est énorme.

• Speaker #1

  Une heure de perte de production à l'époque était estimée à 50 à 60 000 francs, donc on va dire grosso modo 10 000 euros aujourd'hui. 5 à 6% d'amélioration de TRS sur une usine à feu continu, 365 jours par an, 3 postes par jour. Je crois que si je fais un calcul rapide, c'est 5 millions d'euros par an. Je ne dis pas que le service maintenance, ou du moins le service dans lequel j'ai travaillé à l'époque, je ne connais plus nos coûts de fonctionnement, mais on est presque arrivé à montrer qu'un service maintenance pouvait être une source de gains, plutôt qu'un centre de coûts.

• Speaker #0

  C'est pas évident, hein ? On nous a retrouvés,

• Speaker #1

  mais j'en étais pas loin. Donc voilà. Le fait de travailler de cette manière-là m'a aussi permis de montrer qu'on progressait. D'année en année, le TRS s'améliorait du fait de notre travail. Et je n'ai jamais eu à subir de réduction de nombre de personnes, ni de réduction de budget de maintenance. Bien sûr, les budgets de maintenance devaient toujours être limités, mais on n'a jamais subi des réductions de nombre de personnes drastiques. voire des réductions de budget drastiques parce qu'on savait ce que nous faisions de l'argent qu'on mettait dedans. Ce n'était pas vraiment considéré comme un centre de coût. C'était ce qui m'a fait rester d'ailleurs pendant 25 ans dans la même société et que le travail était très intéressant et était valorisé.

• Speaker #0

  En final, vous aviez vos objectifs, vous aviez les mêmes objectifs que la production, donc on pouvait évaluer vos performances tout le temps.

• Speaker #1

  Tout à fait. Et on avait aussi réussi à établir un dialogue de confiance avec la production. J'ai trop souvent vu dans mes expériences après où la maintenance et la production s'affrontaient à longueur de journée et le fait d'avoir mis en place cette relation de confiance avec une totale transparence entre les deux services a toujours permis de travailler sur des choses efficacement. On était arrivé à un point où l'opérateur pensait que le fait qu'on enregistrait de plus en plus de données, ils pensaient qu'on enregistrait tout ce qui se passait sur la ligne. Ce qu'on enregistrait entre autres, c'est les boutons. Quand un opérateur appuyait sur un bouton, marche, arrêt, un certain nombre de données, on les avait, elles étaient enregistrées. Donc on pouvait dire à un moment, oui, la machine s'est arrêtée, mais en même temps, un opérateur a appuyé sur ce bouton-là. La première fois que c'est sorti, j'ai demandé à mon supérieur, qu'est-ce qu'on fait ? J'ai vu que l'opérateur a fait une bêtise, il ne devait pas appuyer sur ce bouton, il l'a fait. L'outil est là pour ça. on est en parfaite transparence, on y va. À partir de ce jour-là, l'ensemble de la production pensait qu'on enregistrait tout en permanence et qu'il y avait tout intérêt à dire oui, j'ai fait une bêtise, désolé et nous, ça nous évitait de chercher pendant des heures des problèmes qui n'en étaient pas. Je crois que c'est le plus gros gain d'efficacité qu'on a réussi à faire. Dans ma vie professionnelle, c'était le plus gros gain d'efficacité. La confiance et de dire que ce n'est pas la peine de vouloir tricher, on sait. Grosse satisfaction.

• Speaker #0

  Du coup, la réaction est faite sur je me dévoile plutôt que de créer en plus de défiance, oh là là tu m'espionnes. C'est bien que ça ait tourné dans ce sens-là.

• Speaker #1

  Voilà, la limite est fine, tout à fait.

• Speaker #0

  C'est vachement intéressant. Du coup, dans la GMAO, est-ce qu'il y a des fonctionnalités qui t'ont un peu déçu ? Des choses, tu nous as dit que le module de maintenance préventive n'a pas forcément été mis en place.

• Speaker #1

  Alors le module de maintenance préventive, je crois, n'existait pas. Et je me débrouillais, seul, dans mon coin. à basculer du fichier Excel de suivi de maintenance préventive à un logiciel de gestion de base de données qui me permettait de faire des plannings de maintenance préventive qui étaient distribués aux techniciens, qui faisaient le travail et qui ensuite, par un retour, mettaient à jour le fichier Excel. C'était un peu... Oui, ce n'était pas intégré. Il me semble que si ça avait été intégré dans la GMAO de l'époque, je pense que je m'en serais servi. Je n'ai pas le souvenir que ça l'était.

• Speaker #0

  C'est très intéressant ce que tu dis parce que... C'est quelque chose que je mets souvent en avant aussi. Quand tu veux te faire assister par le numérique, finalement, là, vous avez numérisé toute une partie acquisition de données, un processus que vous maîtrisiez parfaitement, même si ça a rajouté un peu de travail aux gens d'éviter de dire à la machine à café J'ai fait ci, j'ai fait ça, là, il fallait le renseigner dans le logiciel. Derrière, ça, ça te dégage du temps parce que tu n'as plus à fliquer ça, tu n'as plus à savoir, à chercher par toi-même ce qui s'est passé sur ceci ou cela. Mais du coup, tu as le temps. pour faire tes plannings de maintenance préventive.

• Speaker #1

  Tout à fait.

• Speaker #0

  Derrière, quand tu avances sur ta maintenance préventive, tu peux te dire un peu plus tard, Ok, maintenant je maîtrise parfaitement comment je fais mes plannings, je peux me faire aider par le numérique. Et on peut itérer comme ça. Mais effectivement, si on ne commence jamais, on ne se dégage jamais le temps pour détricoter la plotte, finalement.

• Speaker #1

  Ça nécessite effectivement au début un investissement personnel, peut-être supérieur à ce qui est demandé à la fonction maintenance basique. Mais oui, je me répète peut-être, ma philosophie de vie, c'est qu'est-ce que je peux faire aujourd'hui pour être moins embêté demain. Bon, il est vrai que le lendemain, j'arrive toujours à me reposer la même question, de continuer à essayer de m'améliorer. Mais c'est un principe qui, j'ai bien aimé ça et j'ai toujours fonctionné comme ça.

• Speaker #0

  Je vous le disais dans le premier épisode, mais Dominique, c'est mon papa. Et effectivement, j'ai grandi avec cette idée de savoir perdre du temps aujourd'hui pour en gagner X fois plus demain. Alors. C'est hyper important. Donc, ce n'est pas pour rien que je fais le métier que je fais aujourd'hui. Je pense que je peux dire merci papa. Au niveau des équipes, est-ce que tu as eu des gens qui ont été tout de suite convaincus par l'outil ? Ou est-ce que globalement, ça a été quand même plutôt résistant ?

• Speaker #1

  Globalement, dans mon équipe, j'ai été bien suivi. Parce qu'on est arrivé lors du projet d'installation de l'usine, donc de la machine à papier. On est arrivé tous ensemble, du même âge, d'une même culture. On a tous connu une autre expérience professionnelle à l'extérieur avant, moins intéressante. Généralement, on dit je sais d'où je viens, donc je sais ce que j'ai maintenant Notre entrepreneur à l'époque nous proposait des conditions de travail intéressantes. Ça reste de l'industrie, mais c'était bruyant, effectivement. De temps en temps, peut-être un peu salissant, peut-être un peu chaud aussi. Donc ça reste de l'industrie, mais on savait d'où on est, on connaissait les conditions d'emploi. Chez cet employeur, les rémunérations étaient correctes, donc l'investissement personnel n'était pas un problème. Et j'ai réussi à emmener mon équipe dans mon envie d'amélioration continue. Et donc je n'ai pas eu vraiment de soucis d'emmener mon équipe là où je voulais. 25 ans après, quand la société a fermé et que j'ai dû me réorienter dans d'autres sociétés, je me suis rendu compte que ce qu'il me semblait être un standard normal de ce qu'on avait réussi à mettre en place ensemble, pas moi tout seul parce qu'on est une équipe, que même 25 ans après, ce n'est absolument pas la normalité et que la maintenance préventive, la maintenance conditionnelle et faire mieux toujours le lendemain, ce n'est pas quelque chose d'acquis et même, je dirais, très peu acquis, trop souvent. J'ai eu des réfractaires, effectivement, dans d'autres équipes qui ne voyaient pas l'intérêt de travailler comme ça. Et j'ai une autre petite anecdote où un technicien de mon équipe, un jour, m'a dit Tu vois, les mécaniciens, ils fonctionnent pas comme ça. On les félicite régulièrement le matin parce qu'ils ont fait 24 heures de boulot non-stop pour réparer quelque chose. Donc on les félicite. Nous, on fait notre travail dans l'ombre. On fait notre maintenance préventive. Ça ne tombe plus en panne. Donc on n'a pas cette reconnaissance. Donc là, il faut se méfier parce que le technicien de maintenance, version pompier de service, je ne fais pas trop de maintenance préventive. J'attends que ça casse, je répare et je me fais féliciter. il passe un peu devant le gars qui, effectivement, dans l'ombre, fait son travail pour que l'usine continue à tourner. Il faut faire attention à ça. Ce n'est pas simple.

• Speaker #0

  C'est là où il faut trouver des moyens d'effectivement féliciter des taux de panne qui s'améliorent sur l'année et ne pas juste féliciter le one-shot. Le pompier de service. Oui, le pompier de service qui va faire son travail. Et ça peut être un bon conseil à donner aux entreprises sur trouver des moyens d'évaluer la performance de chacun et pas celle qui est juste visible et immédiate et qui répond à la douleur. qu'on ressent puisque la ligne s'est arrêtée. Tout à fait. Oui, intéressant. En 2010, le groupe auquel appartient ton usine décide de passer sous SAP. Donc, au revoir votre outil de GMA au actuel, tout le monde passe sous SAP. Bon, ça fait quand même 20 ans que l'outil est en place, c'est une très belle longévité. Comment tu perçois ce changement dès le départ ? Parce que c'est clairement une décision extérieure, tu n'es pas moteur là-dedans, on a un nouvel outil pour le groupe et tout doit fonctionner ensemble. C'est quoi ton ressenti à ce moment-là ?

• Speaker #1

  L'outil SAP existait déjà dans le groupe, les ressources humaines étaient déjà sous SAP, un certain nombre d'autres logiciels, d'autres fonctions étaient déjà couvertes par SAP. L'objectif du groupe était de passer l'ensemble des outils sous la suite, je ne sais pas si on appelle ça une suite, sous la suite SAP, et donc le Plant Maintenance PM, et même Material Management, ainsi que les achats. Il était prévu que ce qu'on gérait par la GMAO Multi Maintenance, comme elle s'appelait, devaient être transférés, migrés vers ce nouveau outil. Je partais du principe qu'un nouvel outil, de nouvelles interfaces, plus modernes, c'est sûrement mieux.

• Speaker #0

  Pardon, je rigole, mais c'est parce que je me souviens des premières interfaces SAP.

• Speaker #1

  Voilà. Donc ça n'a pas d'appréhension. C'était une volonté groupe. Les usines françaises du groupe étaient les dernières à être migrées. On avait une seule contrainte, c'est que les autres pays, que ce soit la Finlande, l'Angleterre, l'Allemagne, la Chine, ont déjà toutes été migrées sous SAP. Donc, le logiciel fonctionne. Donc, vous n'aurez pas d'adaptation spécifique à votre besoin. S'il y a des adaptations à faire parce que la loi française l'impose, bien sûr, on le fera. Mais sur la partie fonctionnalité, il a été prouvé que ça fonctionne dans les autres usines. Donc, vous resterez comme ça.

• Speaker #0

  Je ne vais pas m'étendre sur le sujet, mais mon petit cœur saigne d'entendre ça. C'est clairement le métier au service du numérique plutôt que le numérique au service du métier. quelque chose auquel je n'adhère pas du tout, mais ce n'est pas le sujet aujourd'hui, donc on va continuer sur l'implémentation. Comment se déroule le projet en tant que tel, le passage ? Est-ce qu'il y a eu des étapes, des moments un peu critiques qui t'ont particulièrement marqué ? Qu'est-ce qui a tendu de vous ? Comment ça se déroule ?

• Speaker #1

  Dans l'absolu, en tant qu'équipe de maintenance, on ne devait être que très peu impliqués dans le projet. Il y avait une équipe d'un prestataire, si mes souvenirs sont bons, c'était Vipro, boîte d'origine indienne. qui gérait l'ensemble du projet et qui devait transposer, parce que pour moi, pour la partie Plant Maintenance PM, c'était simplement transposer des bases existantes d'un logiciel dans une autre. Pour moi, c'était à peu près le seul boulot. Pendant tout le projet SAP, j'ai vu une seule carte de visite qui était marquée SAP. Toutes les autres cartes de visite étaient soit de chez Siemens, soit de chez Vipro. Donc pour moi, SAP, je n'ai pas de contact avec des gens de SAP. Ce qu'on nous a demandé de faire, ou ce qu'on s'est forcé à faire, on s'est dit, si déjà on part d'une GMAO vers une autre, on va en profiter pour nettoyer tout ce qui a été fait pendant 20 ans. Parce que pendant 20 ans, l'usine a été modifiée X fois, des choses ont été rajoutées, des choses ont été modifiées. La GMAO n'a pas été forcément mise à jour, donc on s'est imposé le travail de nettoyer la base de données qui allait être transférée dans SAP. Ça a été un travail assez conséquent. Là aussi, j'ai été beaucoup aidé pour mon secteur d'activité par notre ingénieur mécanicien qui était assez férue d'informatique et a réussi à m'expliquer en assez peu de temps comment, avec quelques requêtes SQL, on pouvait exporter sous format Excel la base de données avec différents critères de recherche et qui pouvaient m'aider à lister ce qui devait être amélioré et que je pouvais transmettre. au gars de mon équipe, de manière à ce que, au gars de mon équipe ou d'autres équipes, parce que j'avais une fonction effectivement de support pour l'ensemble du projet, de soumettre ça à l'ensemble des techniciens de maintenance, de manière à ce que tous les jours ou toutes les semaines, ils passent 2-3 heures à vérifier des nomenclatures si c'était encore juste et à les corriger de manière à ce que la base à transférer soit propre. C'était un bel exercice, surtout que SAP nous imposait aussi de passer sur 40 caractères, sachant que l'ancien système, nous avions 60 caractères, par exemple, pour la description de l'objet. Et que ces 60 caractères, nous avions l'habitude de les utiliser.

• Speaker #0

  Quand on a de la place, on la prend.

• Speaker #1

  Voilà, donc on avait des dizaines, voire des centaines de milliers de codes objets qu'il fallait trinquer, on va dire, dans un bon français, qu'il fallait raccourcir, tout en faisant en sorte que ça reste compréhensible. Donc voilà, c'était un travail, ma contribution du projet Migration SAP. était vraiment d'assainir la base de données, que ce soit pour les nomenclatures, que pour tous les ordres de travail et tous les rapports d'incidents qui avaient déjà existé dans l'ancien système. Tout a été transféré d'un ancien système à l'autre. Les bases de données n'étaient pas fondamentalement différentes, donc technologiquement, ça n'a pas été un gros souci.

• Speaker #0

  Et il se trouve qu'en 2010, tu as une fille qui est en école d'ingénieur à ce moment-là et qui a besoin d'un stage d'un mois. Et tu te dis que ce serait pas mal de la faire bosser sur le sujet. Petite anecdote, c'est comme ça que j'ai découvert vraiment l'informatique au service de l'industrie et qui a posé les premiers briques de ce qu'allait faire mon métier plus tard. Je referme la parenthèse.

• Speaker #1

  Voilà, sur le projet, donc le projet s'est relativement bien passé. Alors effectivement, ça a été du travail en plus. L'usine continuait forcément à tourner, les travaux de maintenance devaient être faits. Donc on a pris effectivement sur notre temps, on s'est organisé de manière à ce que ce projet arrive à bout. Et on a eu la satisfaction qu'un vendredi après-midi, on a dit maintenant on ne touche plus à l'ancienne GMAO. On nettoie encore un petit peu la base de données le samedi et le dimanche et le lundi matin. On va redémarrer avec le, parce qu'on appelait ça un avis, et puis un rapport d'incident. SAP dit c'est un avis. Nous avons créé notre premier avis qui est rentré dans la GMAO, donc SAP, qui a généré une première demande d'intervention, qui est devenue un premier ordre de travail. Ça s'est passé très facilement. On a eu pas mal de temps, on a eu de la formation, on a pu former nos collaborateurs. La formation n'était pas très très difficile. Ils avaient tous l'habitude de faire des rapports d'incident. Finalement, de renseigner des textes associés, comme on appelait ça, à des incidents, à des heures de travail. Ils avaient l'habitude de pointer des heures. SAP était simplement des interfaces différentes pour faire à peu près la même chose. Donc de passer de multimaintenance à SAP, techniquement, ça n'a pas été très compliqué. On a réussi à gérer assez facilement la formation des techniciens pour passer d'un logiciel à l'autre. Mais on était assez matures au niveau de l'utilisation d'une GMO.

• Speaker #0

  Ok. Et le changement de logiciel, il vous a apporté des choses en plus par rapport à votre ancienne gestion de maintenance ? Parce que j'espère qu'en 20 ans, il y a quand même des choses qui ont bougé sur le sujet.

• Speaker #1

  On utilisait beaucoup notre ancienne GMAO. J'attendais beaucoup du module de maintenance préventive de SAP, qui, une fois qu'on avait démarré, parce qu'on n'a pas décidé, sachant que l'ancienne GMAO ne gérait pas la maintenance préventive, on n'avait pas des bases de données de maintenance préventive. Tout. toute prête à être implémentée dans SAP. Donc, il avait été décidé de, on transfère, on migre tout ce qui doit être migré et on remettra en place tous nos fichiers Excel, toute notre maintenance préventive qui était gérée en dehors de la GMAO. On avait décidé de l'implémenter ensuite. Là, c'était une déception. Les modules de maintenance préventive SAP 2010, aujourd'hui, je ne sais pas parce que j'ai malheureusement assez vite abandonné SAP ensuite. L'outil de maintenance préventive n'était pas d'une convivialité extrême. On a fait quelques tests pendant quelques mois de mettre en place sur quelques machines la maintenance préventive telle qu'elle était prévue par SAP. On n'a pas trop insisté parce qu'à peine 18 mois après la migration, le groupe a décidé de fermer l'usine. Donc voilà, j'ai une petite expérience finalement de SAP de 18 mois. Au niveau... Plant maintenance, très bien, mais il y a la partie maintenance préventive que je ne connais pas, qui a peut-être évolué depuis, mais je ne la connais pas.

• Speaker #0

  La décision du groupe de ne pas refaire de développement spécifique pour vos besoins et vos process, est-ce que ça a eu un impact finalement ? Parce que ça, on vous l'annonce au début sans même savoir comment vous travaillez et si ça va rentrer dans les processus. Est-ce que vous vous en êtes sorti ou est-ce qu'il y a eu des choses où vous avez dû revoir vos processus ?

• Speaker #1

  Ça remonte à presque 15 ans. Il y a eu des discussions longues. où effectivement on dit si ça ne fait pas ça, on ne peut plus travailler. Bien sûr, on l'a dit. Il y a eu des adaptations, il y en a eu quelques-unes de faites et on s'est rendu compte que notre partenaire indien qui a implémenté localement toutes ces petites modifications qui devaient nous permettre de fonctionner, lors de la première grosse mise à jour, tout a disparu. Donc, je n'ai pas essayé de comprendre d'où venait la chose. Mais a priori, ils avaient fait de l'implémentation locale de quelques besoins locaux et qui ont disparu. La première grosse mise à jour était quelques mois après le go live. L'usine était déjà prête à être abandonnée par le groupe. Ça, on l'a appris quelques mois après. Donc, il n'y a pas eu vraiment d'effort de fait pour revenir en arrière. Je me souviens de ça, de cet exemple-là. Je me souviens moins de quel était l'impact réel du fait qu'on n'ait pas fait les ajustements de nos besoins locaux.

• Speaker #0

  Il y a une histoire que tu me racontais en off aussi, le SAP. Vous voulez, je ne sais pas si c'est SAP ou l'intégrateur, mais vous voulez que vous revoyez toutes vos codifications de nomenclature pour correspondre à l'environnement SAP, alors que c'est des nomenclatures qui vous parlaient à vous, et vous vous êtes battu pour ça, vous avez eu gain de cause ?

• Speaker #1

  Oui, tout à fait, on a eu gain de cause sur ce point-là. Officiellement, l'organisation SAP nous obligeait de renommer, par des systèmes alphanumériques, d'une suite de nombres et de lettres, l'ensemble de nos machines, l'ensemble de nos objets. Oui. devait être renuméroté par un nouveau code, qui n'était absolument pas parlant, vu que les machines s'appelaient toutes par un nom, qui commençait par un numéro d'atelier, par une lettre qui disait déjà ce que c'était comme type de machine, ensuite un numéro d'ordre, et au bout de 20 ans, ces numéros-là, on les connaissait par cœur. Et du jour au lendemain, SAP demandait à ce que toute cette nomenclature soit revue par un système de numérotation très peu lisible. Il y a eu beaucoup de discussions, on a eu gain de cause, On a pu rester sur les nomenclatures d'origine. Je n'ai pas vraiment compris le pourquoi du comment on devait changer toute cette nomenclature. Probablement pour des raisons financières, parce que tout ce qui était sous la même racine pouvait financièrement passer sous un cost code bien précis. Donc voilà, on a eu gain de cause, c'était l'essentiel pour nous, en tant que technicien de tous les jours. Voilà, c'était un gros sujet. On a longtemps, longtemps discuté là-dessus et finalement on a continué comme avant.

• Speaker #0

  C'est un sujet qui est important quand on choisit un logiciel. L'exemple, c'est la maintenance, mais on peut souvent avoir des logiciels qui vont répondre à un point précis, mais qui sont dépendants d'un logiciel maître. Clairement, chez SAP, le côté financier domine un peu et finalement, toutes les fonctions autres vont répondre aux besoins de reporting de la finance. C'est bien parce que tout est coordonné et tout va au même endroit. A l'inverse, si je prends un exemple d'un logiciel de notes de frais, il peut aussi bien être lié à un logiciel RH. Si on raisonne beaucoup à une dépense, une personne et je rembourge cette personne. Ou alors à un logiciel de gestion des clients ou de gestion des projets, si les notes de frais sont plus souvent à refacturer avec les clients. Donc ça, ça peut faire partie de la réflexion de comment on choisit un outil. Qu'est-ce qui domine en fait ? Qu'est-ce qui est le plus important ? Est-ce qu'on veut avoir une maintenance très orientée maintenance ou est-ce que finalement la maintenance est pilotée par la gestion financière ? Ou par un autre organe de l'entreprise. Ça peut permettre de savoir comment les logiciels vont être interconnectés entre eux qui est le logiciel maître, finalement. Effectivement, chez SAP, il y a plutôt le côté financier. Et c'est sûrement pour ça que tu l'as ressenti comme ça aussi sur ton logiciel.

• Speaker #1

  C'est probablement.

• Speaker #0

  Je te remercie pour toutes ces informations. C'était très intéressant. Je suis contente de l'avoir partagé avec toi ici. Pour finir, est-ce que tu aurais un conseil pour quelqu'un qui hésite à se lancer dans l'implémentation d'une GMAO ? S'il y a un truc à dire sur le sujet.

• Speaker #1

  Grâce à une GMAO ou à cause d'une GMAO, vous allez obliger l'ensemble du personnel de l'usine, que ce soit le technicien de maintenance ou l'opérateur de production, à écrire ce qu'il a vu, ce qu'il a ressenti. Non seulement ça va être tracé, ça va rester et on pourra s'y référer pour prendre des décisions, mais surtout quand on écrit, quand on essaye d'expliquer quelque chose par écrit, ça nous fait réfléchir à ce qu'on est en train d'écrire. Pendant qu'on écrit, on se dit, ça c'est peut-être... pas passer tout à fait comme ça. Alors quand on fait simplement un compte-rendu à l'oral, on peut en trois quatre mots dire voilà j'ai fait ça, ça, ça et ça et c'est parti. L'information écrite est pour moi beaucoup plus juste. Le souci qu'on a, c'est qu'on a encore trop de techniciens qui n'aiment pas écrire et le souci que peut représenter une GMAO et c'est vraiment la chose qu'il faut bien avoir en tête au début, c'est qu'il faudra faire écrire les opérateurs et les techniciens de maintenance. Il faut les faire écrire ce qu'ils vivent au jour le jour. C'est ça la matière première d'une GMAO. Une GMAO vide ne sert à rien. Si elle n'est pas renseignée, ça ne servira pas à grand-chose. Donc c'est vraiment remplir, remplir, remplir.

• Speaker #0

  Je ne me fais rien de répondre là-dessus parce que je vois souvent des résistances sur le fait de demander à écrire à des gens qui ne sont pas forcément à l'aise avec l'écriture, parfois même avec la lecture. Aujourd'hui, il existe énormément de solutions pour faire des vocaux qui donnent lieu à des transcripts derrière où on a quand même cette... notion d'écriture. Donc derrière, on n'est pas limité par la fonction de recherche qu'on a sur l'écriture et qu'on n'a pas sur le vocal. Et derrière, si vraiment la personne est mal à l'aise avec l'écriture, on peut avoir repassé sur le transcript et l'améliorer un peu. Mais en tout cas, si c'est vraiment le problème, il y a toujours des solutions pour capter l'information là où elle est, même si l'écriture c'est compliqué.

• Speaker #1

  J'imagine assez facilement que des listes déroulantes pour répondre à certains problèmes peuvent résoudre la question. Quand une machine s'est arrêtée et que la personne sait pourquoi, il y a peut-être une dizaine de raisons, elle choisira dans ces dix raisons, on aura toujours la raison, même si ce n'est pas parfait, ça sera toujours plus proche que rien. C'est ça.

• Speaker #0

  Le but, c'est de toujours trouver une manière pour que la saisie d'informations soit la plus simple possible et plus elle est simple, plus elle est fiable.

• Speaker #1

  Je n'ai pas été confronté à ça à l'époque. Les techniciens avaient envie d'écrire. J'avais réussi à les convaincre de m'accompagner dans ce projet, donc ça a été assez facile.

• Speaker #0

  Aujourd'hui, le recrutement dans l'industrie, c'est beaucoup plus compliqué. Et donner envie à tout le monde, c'est aussi passer par des interfaces qui sont simples et conviviales pour des générations qui sont de plus en plus nées avec le numérique dans la main. Donc, proposer du papier-crayon ou d'écrire beaucoup de choses, ce n'est plus très cohérent non plus avec ça. Mais on a des solutions et on s'améliore tous les jours. Je te remercie.

• Speaker #1

  Merci à toi. de m'avoir invité.

• Speaker #0

  Je t'en prie, c'était avec plaisir. Quant à vous, je vous laisse sur ces bonnes paroles et je vous dis à la semaine prochaine. Et voilà, c'est la fin de cet épisode d'Osez l'Efficacité. Je serais curieuse de savoir ce que tu en as pensé. En tout cas, si cet épisode t'a plu, n'hésite pas à laisser un commentaire et à donner un avis 5 étoiles. Ça m'aide énormément. Tu peux aussi me suivre et me contacter sur LinkedIn et Instagram pour continuer la discussion. Je serais ravie d'échanger avec toi. Rendez-vous la semaine prochaine pour un nouvel épisode plein de conseils et d'astuces. pour oser l'efficacité. A très vite !