Blog éclectique & sans sujet précis

On se ressemble beaucoup, Jid, finalement, à un an d’écart. Même situation de famille, même ennui apparemment au boulot, même philosophie de paresseux (qualité première d’un informaticien), même optique du fonctionnement des strates supérieures de l’entreprise.

Je rebondis sur son billet : chercher à faire moins d’erreurs est une chose. Le choix du thermomètre (le moyen de repérer ces erreurs) en est une autre, encore plus critique.
Un informaticien noté uniquement sur le nombre d’incidents réglés par jour/mois aura tendance à les clore au premier prétexte (inactivité apparente du quémandeur...), voire sans. Un hotliner noté sur sa moyenne de temps d’appel raccrochera une fois sur deux sans même écouter. Quelqu’un noté sur le nombre de demandes de modifications du logiciel satisfaites aura tendance à les exiger nombreuses, précises et très courtes. Je n’ose penser aux conséquences du paiement d’informaticiens au nombre de lignes de code pondues...
À l’autre bout de l’échelle, un grand chef payé en fonction du cours de bourse du prochain trimestre ne s’intéressera qu’à ça, allant jusqu’à le manipuler. Tenter de contrôler les gens à ce niveau est illusoire : s’ils étaient contrôlables, ils ne seraient pas assez intelligents et amoraux pour diriger une grosse entreprise...

Pour en rajouter : l’industrie manufacturière est censée être le royaume de la qualité de process. Mais cela vaut principalement pour le produit fini, pas toujours pour le reste, notamment la manière dont la base de données de l’usine est renseignée. De plus, les gens de la Production raisonnent avec des contraintes (temps de mise en place, contraintes de maintenabilité sur le long terme, justesse comptable...) très différentes d’autres services. Donc les choses ne sont pas toujours aussi carrées qu’elles le devraient.

Et tout problème ensuite se focalise à deux endroits :

• la Comptabilité, en fin de mois, parce qu’il y a une incohérence qui saute aux yeux de gens entraînés à les traquer (histoire d’éviter que le fisc hurle à la fraude, ou que les entités commerciales ne voient un bénéfice de l’usine, qu'elles s’empresseraient d’exiger) ; heureusement les comptables sont souvent logiques et placides ;

• la Logistique, parce qu’eux doivent expédier, avec plein de papiers réglementaires, et si quelque chose manque, ils s’en aperçoivent aussi, tout en bout de chaîne ; par contre ce sont des gens assez stressan stressés pour qui tout est toujours urgent : le camion, il est déjà sur leur quai quand le problème se déclare.

Dans les deux cas, le problème devient très vite le problème de l’Informatique, simple moyen mais dont tout le monde attend la même disponibilité et fiabilité que celle du réseau d’eau, et la souplesse et la servilité d’un majordome. Si ça foire, c’est forcément la faute de l’informatique/de l’informaticien, jamais la faute de celui qui a ordonné une aberration au système, qui s’est assis sur les procédures, ou qui s’y est pris au dernier moment, situation que Murphy adore.

Dans le cadre d’un ERP tout dysfonctionnement doit être corrigé matériellement et dans le monde désincarné des tables SQL. Celles-ci après tout sont censées refléter la réalité. Sachant que la logique interne de la bête relève du miracle quotidien, de la magie noire, du vaudou, en plus des maths et des lois comptables, avec une bonne pincée d’influence de gremlins, le tout sous l’œil narquois et vigilant de Murphy, la chose peut être difficile/cauchemardesque/impossible.
Si théoriquement on peut corriger un problème, le délire ergonomique qu’est l'ERP rendra la chose impossible à l’échelle humaine (exemple : 300 clients à modifier, chacun nécessitant 30 s de manipulations à travers 2000 couches de java, de serveur d’application, bases sur un autre continent...)

Des exemples :

• L’entreprise qui fabrique des gadgets électroniques où je facturetravaille possède une base de données mondiale de ses numéros de série de gadgets, base située sur un autre continent que l’usine.
  Suite à divers problèmes, les responsables de cette base exigent (ce sont eux qui payent) que plus aucune livraison ne se fasse tant que les données ne sont pas arrivées chez eux et validées. Même le papier nécessaire au prélèvement dans les stocks n’est plus imprimé. Tout cela part d’une bonne intention.
  Malheureusement, un jour des invendus sont revenus en stock, les personnes adéquates, humaines donc faillibles^[1] n’ont pas transmis cette information, le grand serveur de l’autre continent a donc hurlé au doublon de numéro de série et refusé de valider la nouvelle livraison ; il a donc fallu corriger, de plus un jour de clôture comptable, synonyme de système bien chargé, et, Murphy oblige, des bugs de performance^[2] se sont invités ce même jour. Le livreur attendait que les fichiers d’information traversent les océans pour embarquer les gadgets qu’il voyait bien emballés et rangés sur le quai. Un vendredi soir bien sûr, où la bonne volonté fait très vite défaut, sinon les personnes compétentes. Soyons honnêtes, les problèmes de fuseau horaire ne nous ont pas gênés cette fois. Mais le livreur est reparti sans embarquer.
  De toute façon, les quatre palettes ne tenaient pas dans la camionette.

• Cette même entreprise française est pressurée par ses clientsdonneurs d’ordres de fabriquer et livrer ses gadgets de manière de plus en plus rapide et réactive (histoire d’être au moins aussi compétitive que ces gens aux yeux bridés à des milliers de kilomètres, qui sont plus proches des gisements de pièces détachées, et livrent au final aussi vite sur notre propre continent). La recherche des gisements de productivité fait rage, ainsi que la mode des KPI. On m’a donc demandé de travailler sur un rapport qui permettrait de suivre le « temps de séjour »^[3] de chaque gadget entre la commande, l’ordre de fabrication, sa mise en palette, l’arrivée sur le quai, et le départ vers les comptoirs où des pigeoclients ébahis les acquerront pour une petite fortubouchée de pain.
  Comme tout projet transverse à plusieurs services, personne ne maîtrisait l’intégralité du flux. Le questionnement sur les écrans (« Cette donnée à l’écran elle veut dire quoi ? ») a très vite dégénéré en querelle sémantique sur la notion exacte de « release d’OF » et autres « passage en stock XQ5 ».
  Puis les données pourries ont fait surface, par exemple sous la forme d’ordres de fabrication annulés sans que le système en ait été informé : des palettes en double ça fait mauvais genre.
  
  Finalement après bien des heures perdues, le petit rapport torché en sous-marin est devenu un mini projet-usine qui fidèlement traquait chaque lot de gadgets pour savoir où il s’était attardé.
  Peu après la livraison j’ai arrêté d’en entendre parler. Son contenu ne plaisait pas, toutes les vérités ne sont pas bonnes à dire. Ce n’était pas un bon thermomètre...