-- Leo's gemini proxy
-- Connecting to unbon.cafe:1965...
-- Connected
-- Sending request
-- Meta line: 20 text/gemini;
Une de mes missions à mon poste actuel – en plus d’être paranoïaque sur la manipulation de collection en fluide[1] – est la gestion de l’inventaire, à la fois du consommable mais également de l’appareillage. La personne me précédant n’avait aucune appétence – pour ne pas dire compétence – en informatique, si bien que l’intégralité des documents était jusque là sous format physique avec une copie numérique plus que débraillée. Sans entrer dans les détails, la totalité des fichiers étaient en effet construits sous forme de tableurs – beurk – et au format .xlsx de Microsoft – double beurk. Y voyant un frein majeur à l’efficacité de l’établissement, j’ai décidé d’y mettre mon grain de sel avec au menu, une bonne dose de rangement et un peu de standardisation.
Un inventaire c’est une base de données, en partant de ce postulat j’ai rapidement entamé une migration – manuelle évidemment – de l’ensemble vers du SQL avant de freiner en voyant le niveau d’illectronisme[2] de l’environnement. D’une certaine manière, je vois un inventaire comme un ensemble d’attributs fonctionnant en réseau. C’est à dire que pour un élément donné, je peux renseigner différents champs, tels que la marque, le modèle, la quantité, la localisation, etc. Rien qui ne soit hors d’atteinte à interpréter. Seulement, je ne compte pas occuper indéfinimment ce poste où les critères d’entrées sont très légers. Et il est fort probable qu’une solution trop spécialisée ne soit pas utile voire soit un poids à traîner en absence de bonnes pratiques. Pour dire, des collègues ne maîtrisent pas les fonctions de base du bureautique usuel (traitement de texte et tableur). À aucun moment ce n’est un reproche à leur encontre, tout le monde à ses propres appétences, et c’est avec respect que je cherche à construire et collaborer. De ce fait et appuyé par le retard évident de développement de LibreOffice Base[3], j’ai rayé l’idée d’une base de donnée à proprement parler.
Refusant la fatalité du physique, j’ai tout de même cherché à améliorer le modèle existant et pour cela il a fallu reprendre le processus du début avec la définition des besoins, autrement dit, un cahier des charges[4] :
Nom de l’élément, marque et modèle ;
Référence interne, en particulier pour les appareils ;
Fournisseur ;
Référence auprès du fournisseur ;
Localisation. Les espaces de rangement étant nombreux, il est nécessaire de pouvoir facilement localiser où sont rangés les éléments ;
Quantité. Pas tant pour l’appareillage dont le cycle de vie est plus long mais surtout pour le consommable, il doit être possible de savoir à n’importe quel moment quelles quantités sont disponibles ;
Consommation. Le système doit permettre de suivre l’évolution des quantités de telle sorte à ce qu’il soit possible de pouvoir évaluer la fréquence de commande.
Date de contrôle pour l’appareillage
Simple à la prise en main. Il n’y aura probablement pas de période d’accompagnement à l’utilisation et devra, de fait, être relativement clair et intuitif.
À noter que le coût ne fait pas partie des éléments qu’il m’est nécessaire de suivre, ma liste de fournisseurs étant fixe suite à un appel d’offres je n’ai de toute manière pas le choix quand je dois effectuer un achat. Cette liste dessine une ébauche avec 8 champs différents, la question de consommation pouvant être traitée différemment puisque répondant d’un calcul plutôt que de la simple donnée ; Des inventaires peuvent être dressés à des dates différentes, enregistrés puis comparés pour établir le volume de consommation.
Un des critères clés du système sera de pouvoir déterminer facilement où sont rangés chaque élément. Pour cela une codification est nécessaire[5]. Relativement simple lorsqu’il est question d’un entrepôt arrangé en allées et niveaux, ce modèle n’est pas applicable pour ma situation avec des placards disposés de façon non linéaire dans des couloirs et salles. De plus, un système existe déjà pour la numérotation des salles et doit être pris en compte pour éviter chevauchements et confusions.
A B CC
Soit le modèle en place, alors A correspond au bâtiment, B à l’étage et CC à une valeur comprise entre 0 et 99. La solution me paraissant la plus simple reste encore d’étendre le modèle en rajoutant un suffixe .D – compris entre 0 et 9 – de telle manière à pouvoir indiquer tel placard se suivant la porte de la salle CC. Malheureusement en pratique, la géométrie des salles est telle qu’il peut y avoir plus de 9 placards entre deux portes, d’où la nécessité d’utiliser un suffixe .DD. En cet instant, il ne me paraît pas nécessaire de préciser l’étagère et je passerai outre.
Vient ensuite la question des emplacements internes au salles où le modèle linéaire n’est pas applicable tant il y a de dispositions différentes. La solution qui me paraît la plus simple, puisque de toute manière libre à interprétation reste ici de choisir une numérotation abritraire, avec pour référentiel la porte d’entrée et dans un ordre horaire. Chaque emplacement pourra ainsi être numéroté à l’aide du suffixe DD sans point séparateur.
Une des conséquences du modèle choisi, orienté sur les produits bruts, est la faible capacité d’application aux produits transformés. C’est à mon avis un avantage favorisant les bonnes pratiques retrouvées dans modèle JustInTime [6] où les produits sont le moins manipulés possibles de manière à limiter la péremption. J’ai encore récemment retrouvé une solution préparée en gros volume datant de 1973 et qui était utilisée sans la moindre question, en sachant que le produit hautement volatile n’est considéré efficace que dans les 6 mois après préparation…
Un des problèmes majeurs avec la méthode précédente – encore en place – est le manque de standardisation. L’utilisation du tableur résultait plus d’une contrainte que d’une réelle réflexion ce qui se ressent sur les fichiers qui m’ont été transmis. La première chose que j’ai faite en prenant mon poste fut de mettre en place une synchronisation cloud. Non seulement de manière à pouvoir consulter et intervenir à distance sur les documents – oui, j’aime mon travail – mais aussi et surtout pour pouvoir partager du contenu. Jusque là, l’intégralité des documents était stocké sur seul poste dans un compte local, sans parler des risques liés à la défaillance du disque dur, il était impossible pour le quidam de consulter les documents sans les identifiants de la-dite personne ce qui se révèle être problématique quand ces documents sont la base de travail et d’organisation. Une copie papier existe, mais on retrouve les même difficultés que sous forme numérique, c’est à dire une architecture très personnelle et pas assez objective pour être utilisée par quiconque. Pour exemple, lors d’une absence prolongée et non prévue, il a fallu engager plusieurs jours et personnes pour finalement réussir à s’y retrouver dans ces documents qui parfois n’avaient pas été mis à jour depuis plus de cinq ans. La première étape, et la plus importante, a donc été de faire appel à un hébergement cloud qui, par chance, est proposé et mis en avant par l’établissement, puis d’en partager l’accès avec les collègues[7].
La seconde étape, la plus fastidieuse et encore en cours, est la conversion. Des centaines de fichiers éparpillés dans des dossiers aux noms obscurs à coup d’espaces, de points, d’accents, de chiffres et j’en passe.
> RPM Séances 6x 4è
> RPM 65 étiquettes FRUITS & GRAINES
> Pro PTP MQIS EB PR décembre
Cela ne s’arrête pas là et va plus loin encore, puisque le contenu est également dans un état similaire avec des cases qui débordent, d’autres fusionnées, redimensionnées manuellement, avec des couleurs et abréviations sans légendes… Du pur bonheur. Encore une fois, ç’eut été que moi, un fichier csv[8] simple et sans fioritures aurait suffit. En pratique je me suis résolu à conserver le format tableur qui avait été exclusivement choisi pour sa capacité à entrer les informations de manière arbitraire sur une grille, non sans quelques modifications. Habitude personnelle ou bonnes pratiques, j’use allégrement les modèles et styles[9]. J’ai ainsi créé quelques modèles standardisés pour chacun des documents types comprenant des styles spécifiques.
Cette numérisation du système bien que permettant de gagner en efficacité, repose comme tout standard sur son usage. En parallèle à cela, j’ai entamé un travail de conversion de l’inventaire au fur et à mesure des achats effectué sur l’application Quartzy[10]. Sans être aussi flexible et efficace que je le souhaiterais, cela permet répond néanmoins à certaines de mes attentes telles qu’un suivi des commandes et des références. Le tout de manière centralisée ce qui permettrait d’envisager une collaboration entre les services au sein de l’établissement et limiter les coûts mobilisés, notamment en frais de port. Perfectible, tant pour un usage avancé que simple, j’ai choisi de faire des compromis sur de nombreux points de manière à proposer une amélioration sans créer de fracture, mettant ma petite pierre à l’évolution du système plus que d’en rebâtir un.
-- Response ended
-- Page fetched on Sat May 18 23:40:57 2024