Programme pilote de suivi du matériel : tester avant de déployer

Vous avez choisi votre système de suivi du matériel. Vous avez planifié le déploiement. Lundi prochain, vous basculez tout le monde d'un coup : cinq sites, 500 personnes.

Ne faites pas ça.

J'ai construit UNIO24 parce que je voyais la même scène se rejouer. Une équipe choisit un outil, planifie le déploiement, et saute le pilote parce qu'« on n'a pas le temps ». Elle passe ensuite six mois à rapiécer le système en production pendant que les utilisateurs retournent à la feuille imprimée. Celles qui prennent deux semaines de pilote livrent propre, la plupart du temps. La régularité du motif est brutale.

Je vais vous montrer comment mener un pilote qui attrape les vrais problèmes : le Wi-Fi qui ne porte pas là où vit le matériel, les étiquettes qui pâlissent en quinze jours, le geste de cinq minutes qui devrait en prendre trente secondes. Testez petit, trouvez-les tant qu'ils sont bon marché, déployez sur un système déjà dérisqué.

Pourquoi le pilote n'est pas optionnel

Un pilote ressemble à de la bureaucratie. C'est de la réduction de risque déguisée en procédure.

Un bon pilote fait cinq choses. Il sort les problèmes techniques avant qu'ils ne deviennent des catastrophes : le Wi-Fi de l'entrepôt atteint-il le fond, le serveur encaisse-t-il cinquante scans simultanés, vos étiquettes survivent-elles à leur environnement réel. Il révèle des frictions que personne n'avait prévues, celles qui sortent quand on scanne avec des gants, ou qu'il faut suivre un portable resté sur sa station d'accueil. Il vous donne une boucle de retour tant que vous pouvez encore changer de système, revoir votre stratégie d'étiquetage ou refaire votre structure de données ; après le déploiement, vous êtes coincé. Il fabrique des ambassadeurs, parce que ceux qui ont façonné le processus le défendront ensuite. Et il démontre le retour avant que le gros chèque ne parte, ce qu'une direction sceptique a besoin de voir.

Le risque d'un projet de suivi du matériel ne disparaît pas parce que vous l'ignorez ; il ressort plus tard, sous une forme pire, avec plus de témoins. Compter le coût total de possession, c'est compter ce risque dès le départ.

Choisir son pilote : un service, un site, ou les deux ?

On ne pilote pas « un petit peu de tout » : ça s'appelle un déploiement bâclé. Il vous faut un périmètre assez représentatif pour valider vos hypothèses et assez petit pour rester tenable.

Trois formes fonctionnent.

Un service, tous les sites. Tout le matériel informatique de l'entreprise, rien d'autre. Ça marche quand vos processus sont standardisés d'un site à l'autre et qu'une famille d'équipements a des exigences propres (l'informatique, les véhicules). Le défaut : vous ne testez pas la variété, et un fauteuil de bureau ne se comporte pas comme une perceuse.

Un site, toutes les familles. Tout au siège, nulle part ailleurs. Ça marche quand vos sites diffèrent beaucoup (bureau, entrepôt, chantier) et que vous voulez couvrir toute la gamme. Le défaut : vous ratez les problèmes propres aux autres sites, comme la zone blanche au fond de l'entrepôt.

Le mixte. Un site représentatif, plus deux ou trois familles aux usages différents : le siège, le parc informatique, le mobilier, l'outillage. Vous obtenez de la variété — cher contre bon marché, mobile contre fixe, souvent transféré contre jamais bougé — sans périmètre ingérable. C'est la forme que je choisirais presque partout, que vous gériez le matériel d'une association ou d'un lieu de culte ou celui d'un gestionnaire immobilier.

Ce qui fait un bon site pilote

Prenez un site représentatif (ni le plus facile ni le plus difficile), accessible pour intervenir sur place, de taille moyenne — assez grand pour faire sortir des problèmes, assez petit pour rester pilotable — et volontaire : des utilisateurs récalcitrants condamnent le projet.

Écartez le plus petit et le plus simple, il ne révélera rien de la complexité réelle ; le plus chaotique aussi, vous n'y récolterez que de la frustration. Évitez les sites distants où vous ne pouvez pas mettre les mains. Et ne pilotez nulle part où une perturbation majeure est en cours : déménagement, réorganisation, changement de direction.

Combien d'équipements

Ma règle empirique :

Plancher : cinquante équipements et cinq utilisateurs actifs ; en dessous, l'activité ne suffit pas à éprouver de vrais flux. Plafond : 10 % du parc, au-delà duquel vous faites un déploiement complet sous un autre nom.

Définir le périmètre du pilote

« On essaie et on verra » n'est pas un plan. Un périmètre flou produit des résultats flous. Quatre choses se posent explicitement.

Ce que vous testez. Les familles incluses (portables, écrans, bureaux, sièges) et les familles exclues. Écrivez-les, pour que personne ne suppose. Les limites géographiques (bâtiment A, étages 1 à 3, réserve comprise, salle serveurs exclue). Les groupes d'utilisateurs : les services généraux, l'informatique, la maintenance, pas l'ensemble des salariés.

Ce que vous mesurez. Fixez les critères de réussite avant de commencer : temps pour localiser un équipement, taux d'équipements dont on répond, adoption, erreurs de saisie, temps passé sur les tâches liées au parc. Les chiffres viennent plus bas.

Les processus que vous testez. Pas seulement le logiciel, tout l'enchaînement : entrée d'un nouvel équipement, étiquetage, sorties et retours, transferts, mise au rebut, et oui, l'inventaire physique pendant le pilote lui-même.

Ce que vous ne testez pas encore. L'intégration aux autres systèmes, à garder pour le déploiement. Les rapports complexes, pendant que vous tenez le cœur. Les fonctions avancées sans usage immédiat. Les personnalisations dont vous n'êtes pas sûr : c'est ce dernier point qui tue les pilotes par dérive de périmètre, sur un « tant qu'on y est, on pourrait aussi… ». Si vous partez d'un tableur, notre guide de passage du tableur à un logiciel de suivi traite le sujet.

Le calendrier : combien de temps un pilote doit-il durer ?

En dessous de deux semaines, vous attrapez les problèmes techniques évidents mais pas les frictions qui n'apparaissent qu'avec le temps, et personne ne prend d'habitude. Au-delà de trois mois, l'élan meurt ; les gens oublient que c'est un pilote et le traitent comme du définitif-mais-cassé.

Le bon créneau pour la plupart des organisations : quatre à huit semaines.

Semaines 1 et 2, l'installation et les premiers usages. Paramétrez, étiquetez les équipements du pilote, importez les données de départ, formez les utilisateurs, mettez-les en situation réelle. Vous guettez les incidents techniques et le « ce bouton ne marche pas ».

Semaines 3 à 5, le test grandeur nature. Le système est dans l'usage quotidien, les flux réels tournent, les premiers problèmes de processus deviennent visibles, et vous voyez quelles fonctions servent et lesquelles dorment. Vous guettez les frictions, les manques, les trous de formation, la qualité des données.

Semaines 6 à 8, l'évaluation. Retours formels, analyse des données d'usage, test des ajustements faits en route, mini-inventaire pour vérifier la qualité des données, décision. Vous guettez deux choses : si les améliorations ont tenu, et si le système règle le problème de départ.

Quand il faut comprimer

Le calendrier ne se soucie pas de l'idéal. Inventaire annuel dans six semaines, pression réglementaire, direction impatiente. Un pilote comprimé de deux à trois semaines marche, mais seulement avec des moyens dédiés, un chef de projet expérimenté et des besoins simples :

• Semaine 1 : installation intensive, formation, premiers tests.
• Semaine 2 : usage opérationnel complet, point quotidien.
• Semaine 3 : recueil rapide des retours et décision.

Ne comprimez pas dans un environnement complexe. Le travail du pilote est de trouver des problèmes ; moins de temps, moins de problèmes trouvés.

Les indicateurs : mesurer ce qui compte vraiment

« Est-ce que le pilote a marché ? » est une question inutile. Il vous faut des critères précis, posés avant le départ. Voici quoi suivre, et à quoi les chiffres doivent ressembler.

Performance technique

Le système doit être fiable. Visez plus de 99 % de disponibilité : si les gens n'y accèdent pas, c'est déjà perdu. Un scan mobile doit aboutir en moins de trois secondes, du QR code à la fiche ; plus lent, et chacun trouve des prétextes pour ne pas scanner. La fiabilité de la synchronisation est le tueur discret : vérifiez que les scans faits hors ligne remontent au retour du réseau. Un scan perdu, c'est une donnée perdue, donc de la confiance perdue, et la confiance ne revient pas.

Adoption

Vous voulez que plus de 80 % des participants se servent du système chaque semaine ; suivez les connexions et les opérations par personne. Si la moitié décroche, votre déploiement s'écrasera au contact d'humains ordinaires.

Le respect du processus dit si le système épouse le travail réel. Comparez ce qui se passe physiquement et ce qui est enregistré. Si plus de 90 % des transferts ne sont pas saisis, les gens contournent l'outil : votre processus est cassé, réparez-le maintenant.

Le temps avant autonomie est l'indicateur de recette auquel je tiens le plus. Un utilisateur doit accomplir les tâches de base seul au bout de deux jours. S'il faut lui tenir la main après une semaine, c'est l'interface ou la formation qui cloche.

Impact métier

Le temps de localisation d'un équipement doit baisser d'au moins la moitié. Demandez aux utilisateurs d'estimer avant et après. Si la recherche ne va pas plus vite, à quoi bon.

Responsabilité du parc : plus de 95 % des équipements du pilote doivent avoir un emplacement et un détenteur connus. Faites un inventaire physique à la fin pour vérifier. Si vous n'en répondez pas après le pilote, vous n'en répondrez pas après le déploiement.

Exemple tiré d'UNIO24 : un registre de pilote avec des préfixes d'identifiant par classe (IT- pour l'informatique, TN- pour le transport, MB- pour le mobilier), chaque ligne portant un détenteur — un emplacement comme Warehouse #2, un prestataire comme Universal IT Service, ou une personne avec son service — et des statuts entre inactif, en service et en maintenance. Voilà à quoi ressemblent 95 % de responsabilité : colonnes Holder vides, préfixes manquants et dates Updated figées sont les endroits où creuser.

Exactitude des données : plus de 95 %. Emplacement, statut et affectation correspondent à la réalité quand vous allez vérifier sur place. Des données pourries dans le pilote donnent des données pourries en production. Comptez aussi les équipements retrouvés : découvrir du matériel « disparu » paie le pilote et vend le déploiement.

Satisfaction des utilisateurs

Plus de 70 % des participants doivent recommander le déploiement. Si vos premiers adoptants enthousiastes ne le font pas, quelque chose est franchement cassé. La facilité perçue doit tourner autour de 4 sur 5 dans les questionnaires. La valeur perçue compte le plus : écoutez si quelqu'un dit « ça m'aide à faire mon travail ». Si le système passe pour de la paperasse en plus, aucune formation n'y changera rien. C'est de la conduite du changement, pas de la pédagogie.

Recueillir les retours : les bonnes questions au bon moment

N'attendez pas la fin pour demander « alors, ça va ? ». À ce moment-là, ceux que ça agace ont déjà décroché.

La première semaine, faites des points de cinq minutes tous les jours, de vive voix ou par message. Demandez ce qui est confus, où ça bloque, ce qui traîne, s'ils voient des erreurs. Le quotidien est indispensable ici : un bouton mal placé qui coûte trente secondes par scan coûtera 500 minutes sur la durée du pilote. Réparez-le tout de suite. C'est une des erreurs de gestion de parc que je vois le plus souvent, repousser les corrections « au déploiement ».

Semaines 2 et 3, passez à un questionnaire hebdomadaire court : cinq questions, deux minutes. Note de facilité de 1 à 5, la tâche la plus longue de la semaine, ce qu'ils changeraient, la fonction qui leur manque, plus un champ libre pour ce à quoi vous n'avez pas pensé. L'hebdomadaire fait apparaître les tendances : quand trois personnes demandent la même chose sans s'être concertées, ça compte.

Semaines 4 à 6, menez des entretiens individuels de quinze à trente minutes. Déroulez la journée type. Où le système aide, où il gêne, sont-ils plus ou moins productifs, voudraient-ils le garder, qu'est-ce qui le ferait passer de correct à excellent. Le questionnaire donne des données ; l'entretien donne le pourquoi du problème, pas seulement son existence.

À la fin, un dernier questionnaire et un débriefing collectif. Le questionnaire couvre la satisfaction globale (de 1 à 10), la recommandation oui/non, les trois choses qui marchent, les trois à améliorer, les inquiétudes sur l'élargissement. C'est le débriefing qui vaut le plus : réunissez les participants et laissez-les se parler entre eux, pas à vous. Comparer, débattre, rebondir les uns sur les autres fait sortir ce qu'aucun questionnaire ne capte.

Une question que j'ajouterais partout : « Si on déployait ça dans toute l'entreprise demain, vous seriez content ou inquiet ? » Elle traverse la politesse. Si vos premiers adoptants, le public le plus favorable que vous aurez jamais, répondent inquiets, vous n'êtes pas prêt.

Les problèmes que vous allez trouver

Tous les pilotes que j'ai observés font remonter une variante de la même poignée de problèmes. Les connaître d'avance ne les évite pas, mais raccourcit le temps passé à comprendre.

Le Wi-Fi ne porte pas jusqu'au matériel. On ne scanne pas dans certaines zones, faute de réseau, et un scan qui ne marche pas là où vit l'équipement ne sert à rien. Le remède : le mode hors ligne, que toutes les applications modernes ont, des bornes supplémentaires sur les zones qui comptent, ou des appareils en 4G pour les endroits vraiment isolés. Dans tous les cas, testez dans l'environnement physique réel, pas au bureau. Les cartes de couverture Wi-Fi mentent.

Enregistrer un transfert prend trop de temps. Quand le geste numérique est plus lent que l'ancien, l'adoption échoue. Identifiez les étapes lentes, ne les devinez pas. Supprimez les champs inutiles : avez-vous vraiment besoin des quinze pour un transfert ? Activez les actions en masse, pour transférer dix objets d'un coup. Scannez au lieu de saisir. Chronométrez chaque geste courant ; au-delà de trois clics et trente secondes, simplifiez.

Les étiquettes se décollent, pâlissent ou ne se lisent plus. Elles ne survivent pas à leur environnement, et une étiquette illisible rend le travail d'étiquetage inutile. Testez la durabilité en conditions réelles pendant le pilote : collez-en une sur une machine et regardez-la quinze jours plus tard. Passez au polyester plutôt qu'au papier, aux plaques métalliques pour les milieux durs, au pelliculage pour l'extérieur et le très manipulé. Le NFC mérite un examen sur les surfaces métalliques ou en cas d'exposition chimique, là où un code imprimé ne tiendra pas. Les bonnes pratiques d'étiquetage traitent le sujet en profondeur, et le comparatif QR, NFC et RFID aide à choisir.

Personne ne sait dans quelle catégorie ranger. « Un clavier sans fil, c'est du matériel informatique ou de la fourniture de bureau ? » Une catégorisation incohérente détruit les rapports et rend la recherche impossible. Faites un arbre de décision simple : ça se branche, c'est de l'informatique ; vous vous asseyez dessus, c'est du mobilier ; ça a un moteur, c'est une machine. Réduisez le nombre de catégories, dix valent mieux que quarante-sept. Donnez des exemples pour chacune. Laissez les gens cocher « je ne sais pas » plutôt que de les forcer à se tromper. Votre arborescence vous paraît limpide ; elle est opaque pour tous les autres.

Les participants ne comprennent pas qu'ils doivent vraiment s'en servir. Une participation passive ne teste rien. Posez les attentes au lancement. Faites-en une partie du travail pendant la durée du pilote, pas quelque chose à caser entre deux tâches. Désignez un coordinateur qui passe régulièrement. Et saluez la participation, pas seulement les résultats : les gens ont besoin de savoir que leur engagement compte.

Les données étaient fausses dès le premier jour. Importez l'existant sans le nettoyer et vous démarrez avec des ordures ; la confiance part immédiatement. Nettoyez avant le lancement : le guide de migration et de nettoyage des données déroule la méthode. Vérifiez un échantillon avant d'importer le tout. Lancez un mini-inventaire en première semaine, tant que les erreurs restent gérables. Et soyez franc : « On sait que certaines fiches sont fausses, aidez-nous à les trouver » installe une collaboration là où « voici la nouvelle source de vérité » installe de la frustration.

Ce qui tient à l'échelle du pilote et casse à l'échelle réelle

Voici le piège qui ruine les pilotes réussis : vingt utilisateurs motivés, des données impeccables, des retours élogieux, puis cinq cents utilisateurs au déploiement et tout s'effondre. Petite échelle et grande échelle ne sont pas le même jeu.

Pendant le pilote, celui qui a une question la pose à Bob, le chef de projet. À cinq cents utilisateurs, Bob se noie : le délai passe de cinq minutes à cinq jours, les gens s'agacent, ils abandonnent. Le remède est un support en autonomie construit avant le déploiement : une documentation cherchable avec des captures d'écran, une FAQ tirée des vraies questions du pilote, des vidéos courtes pour les gestes courants (on regarde une vidéo quand on ne lira jamais un manuel), des référents formés par service, et une voie d'escalade quand le référent bloque.

Les participants du pilote se sont portés volontaires ou ont été choisis. Ils sont motivés, ils pardonnent les petits défauts, ils remontent des retours sans qu'on leur demande. Ceux du déploiement n'ont rien demandé, ils ont leur propre travail, et ils ne pardonneront pas la friction : ils arrêteront de s'en servir. Donc traitez chaque point de douleur sérieux avant d'étendre. Expliquez le pourquoi, plusieurs fois. Rabotez chaque friction que vous pouvez raboter. Et saluez publiquement les services qui jouent le jeu.

Avec cinquante équipements, vous vérifiez la qualité des données à la main chaque semaine ; avec cinq mille, c'est impossible et la qualité se dégrade. Mettez en place des contrôles automatiques avant le déploiement : équipements sans emplacement, numéros de série en double, dates de dernier passage suspectes. Installez une stratégie d'inventaire tenable, avec des contrôles tournants plutôt qu'un inventaire annuel censé tout rattraper. Et faites de la qualité des données la responsabilité nommée de quelqu'un : ce qui est à tout le monde n'est à personne.

Le chef de projet fait tout à l'échelle du pilote : il paramètre, forme, importe, répare, répond. À l'échelle réelle, les goulots se forment partout. Documentez ce qu'il sait pendant qu'il en reste le temps, formez d'autres administrateurs, et découpez les rôles entre des propriétaires distincts : formation, qualité des données, support technique.

Ajouter un équipement prend cinq minutes dans le pilote. Très bien. À l'échelle réelle, vous en ajoutez cinquante par semaine, soit quatre heures hebdomadaires. Allégez la saisie : moins de champs obligatoires, des valeurs par défaut intelligentes. Activez l'import en masse pour entrer vingt portables identiques d'un coup, et branchez les achats pour créer la fiche depuis le bon de commande.

Règle empirique : multipliez l'effort du pilote par votre facteur d'échelle. Une heure par semaine à cinquante équipements, c'est vingt-cinq heures à vingt-cinq fois l'échelle.

La décision d'étendre ou non

Le pilote est fini. Vous avez des données, des retours, de l'expérience. Décidez sur des preuves, pas sur de la politique ni sur ce que vous avez déjà dépensé.

On étend, automatiquement, si tout ceci est vrai : la performance technique atteint les cibles (plus de 99 % de disponibilité, scan rapide), l'adoption dépasse 80 %, l'exactitude des données dépasse 95 %, au moins 70 % des participants recommandent le déploiement, aucun problème bloquant n'est apparu, et le retour se démontre en temps gagné, en matériel retrouvé ou en efficacité. Avancez, et faites des participants vos ambassadeurs.

On n'étend pas, si l'un de ceux-ci est vrai : le système est régulièrement indisponible, les gens le contournent, des flux critiques sont cassés, la qualité des données est pire qu'avant, le budget ou le soutien de la direction s'est évaporé, ou l'éditeur n'arrive pas à corriger les problèmes critiques. Arrêtez. Réparez les fondations, changez de système de suivi, ou revoyez l'approche. Ne forcez pas en espérant que ça s'arrange.

On étend avec des corrections est l'endroit où atterrit la plupart des pilotes. L'essentiel marche, mais il reste des problèmes sérieux : performance technique acceptable sans plus, adoption entre 60 et 75 % (bien, pas excellent), quelques frictions, des utilisateurs qui voient la valeur mais gardent des réserves, une qualité de données en progrès et pas encore au niveau.

Posez quatre questions. Les problèmes sont-ils réparables ? Les techniques le sont presque toujours ; une inadéquation de fond entre l'outil et le travail, souvent pas. Combien de temps prendront les corrections ? Deux semaines, raisonnable ; six mois, vous n'êtes pas prêt. Répondront-elles aux inquiétudes des utilisateurs ? Demandez-leur. Pouvez-vous attendre ? Une pression extérieure impose parfois un calendrier médiocre. Ensuite, corrigez les trois à cinq problèmes principaux, refaites deux semaines de mini-pilote, et tranchez.

Une grille de notation, si vous en voulez une

Certaines équipes trouvent utile de chiffrer la décision :

8,0 et au-dessus : on y va. De 6,0 à 7,9 : corrigez, puis allez-y. En dessous de 6,0 : du travail de fond vous attend. Ajustez les poids à votre maison ; si la satisfaction est critique dans votre culture, donnez-lui 30 %.

Communiquer les résultats du pilote

Le pilote est fini, vous avez décidé. Reste à le dire.

Pour la direction

Une page. Un comité de direction ne lit pas quarante pages.

Mettez-y le cadre du pilote (quoi, quand, avec qui), les indicateurs clés en chiffres, une ou deux réussites concrètes, les problèmes rencontrés et leur résolution, les risques restants sans les minimiser, la recommandation, et la suite avec calendrier et moyens. Commencez par les résultats, pas par le processus. « Les participants ont réduit de 60 % le temps passé à chercher du matériel » bat « toutes les activités prévues ont été menées dans les délais ».

Pour l'équipe de mise en place

C'est votre mémoire collective. Documentez tout : périmètre et calendrier, participants et taux de participation, retours classés par thème, incidents techniques et leur résolution, changements de processus faits en route, comparaisons avant/après chiffrées, leçons, recommandations pour le déploiement, et en annexe les questionnaires, les notes d'entretien et les données d'usage.

Dans six mois, quand vous chercherez pourquoi le déploiement coince quelque part, ce document vaudra de l'or. Dans un an, quand vous piloterez un autre système, c'est lui votre méthode.

Pour les futurs utilisateurs

Si vous étendez, l'annonce pose les attentes et crée l'envie. Donnez les résultats concrètement. Montrez ce qui a marché, et que vous avez écouté : « d'après ce qu'on a appris, on a simplifié le transfert et ajouté le mode hors ligne ». Posez des attentes nettes : « vous serez formé deux semaines avant le passage de votre service ». Raccrochez à ce qui les intéresse : « moins de temps à chercher, plus de temps sur le vrai travail ».

Le ton : confiant, sans balayer les inquiétudes. « On sait que le changement est pénible. On a testé sérieusement, et ça marche » bat « ça va être génial ».

Les participants comme ambassadeurs

Ce sont vos meilleurs atouts pour le déploiement. Ils ont utilisé le système, ils savent qu'il fonctionne, ils répondent à leurs collègues avec une crédibilité que vous n'aurez pas. Reprenez leurs phrases dans les annonces. Faites-leur co-animer la formation dans leur service : la formation entre pairs porte mieux que l'instruction descendante. Faites-en les personnes à qui on s'adresse dans leur périmètre. Et reconnaissez publiquement ce qu'ils ont apporté.

Votre liste de contrôle

4 à 6 semaines avant

• Définir le périmètre (services, sites, familles d'équipements)
• Choisir les participants (volontaires, représentatifs, joignables)
• Fixer les critères de réussite et les indicateurs
• Caler le calendrier : début, fin, évaluation
• Communiquer le plan à la direction et aux participants

2 à 3 semaines avant

• Paramétrer le système pour le pilote
• Préparer les étiquettes
• Nettoyer les données à importer
• Créer les supports de formation
• Ouvrir les canaux de retour (questionnaires, entretiens)

La semaine d'avant

• Étiqueter les équipements du pilote
• Importer les données de départ et les vérifier
• Former les participants, en pratique
• Distribuer les fiches d'aide
• Ouvrir les canaux de support

Pendant le pilote

• Point quotidien la première semaine
• Questionnaire hebdomadaire ensuite
• Traiter les incidents techniques tout de suite
• Consigner retours et problèmes
• Faire les corrections faciles au fil de l'eau
• Suivre les indicateurs d'usage

À la fin du pilote

• Questionnaire final
• Entretiens ou débriefing collectif
• Inventaire physique pour vérifier les données
• Calculer tous les indicateurs
• Analyser ce qui a marché et ce qui non

Après le pilote

• Note de synthèse pour la direction
• Rapport détaillé
• Décision d'étendre ou non, grille à l'appui
• Si oui : plan de déploiement fondé sur les leçons
• Sinon : la liste écrite de ce qu'il faut réparer
• Communiquer les résultats aux parties prenantes
• Remercier les participants

Pourquoi ça me tient à cœur

J'ai fait de ces motifs les contraintes de conception d'UNIO24.

Le mobile hors ligne d'abord, parce que j'ai vu trop d'équipes abandonner un système la première fois que le Wi-Fi de l'entrepôt est tombé en plein scan. Les cinquante premiers équipements gratuits, sans carte bancaire et sans essai qui expire, parce que je veux que vous meniez un pilote au lieu de négocier un achat avant de savoir si l'outil convient. L'import et le transfert en masse, parce que l'écart entre cinq minutes et trente secondes par geste tue l'adoption entre le pilote et l'échelle. Une arborescence de catégories volontairement courte, parce que regarder des gens deviner une catégorie est un problème de processus déguisé en problème d'interface.

Rien de tout ça n'est là par hasard, mais parce que j'ai vu les mêmes problèmes casser les mêmes déploiements, et que j'ai ensuite construit un produit qui ne rend pas ces erreurs plus faciles.

Faites le pilote. Trouvez les problèmes tant qu'ils sont petits. Si UNIO24 vous y aide, tant mieux : commencez votre pilote gratuitement. Si autre chose vous va mieux, prenez-le. Ne sautez simplement pas le pilote.