Contexte
Un des sous-modules de l'ERP de pharmacie, pour réceptionner les produits commandés.
Enjeux
Permettre aux membres de la pharmacie de réceptionner les produits commandés efficacement, facilement et de manière fiable pour la gestion de stock.
Discovery
User research
J'ai assisté sur site à plusieurs réceptions de commandes pour bien m'imprégner du sujet :
- Dans des grandes pharmacies des quartiers d'affaires.
- Dans des pharmacies des quartiers populaires.
Enseignements
- Le process de réception reste identique, quel que soit le type de pharmacie.
- Sauf exception, il n'y a pas de corrélation entre un bordereau de livraison (BL) et une commande.
- Le processus est en 2 temps, seule la personne avec les droits peut valider la réception, et ainsi provoquer la mise à jour du stock.
- Importer directement le BL en CSV dans l'application rendrait le processus beaucoup plus rapide.
- Risques élevés de confusions entre les références de produits qui se ressemblent beaucoup.
Le résultat exhaustif de cette recherche est disponible dans ce document : Réception de commande. (C'est un export Notion, la mise en page est altérée.)
Priorisation MVP
Nous commençons la conception du MVP en priorisant les fonctionnalités core (réceptionner les produits pour mettre à jour le stock, et tout ce qui touche à la gestion financière) et en réservant les autres pour des itérations ultérieures.
MVP
- Créer un objet Réception avec les informations importants (n° du BL, date, fournisseur, etc).
- Ajouter des produits dans cette réception, avec les informations nécessaires (quantités, prix, etc).
- Supporter l'ajout de produit par scan limitera le risque d'ajouter le mauvais produit.
- Afficher une synthèse à la fin pour contrôler les chiffres entre le BL et le calcul de l'application.
- Validation et mise à jour du stock par une personne autorisée.
Pour plus tard
- Import du BL CSV.
- Gestion des dates de péremption.
- Déconditionnement des produits réceptionnés.
- Gestion des réclamations.
- Impression des étiquettes.
- Suivi de la facturation.
- Chaînage de ces parcours.
- ...et bien d'autres facilités.
A la suite de ces décisions, nous avons travaillé le workflow suivant :
Wireframes
Les premières du logiciel ont été réalisées avec 3 fonctionnalités : la gestion de stock, les inventaires, et la vente.
La réception de commande arrive dans un environnement applicatif déjà en place et va inaugurer une nouvelle entrée dans la navigation principale : Commandes.
Pour gagner du temps et raccourcir notre Go-To-Market, j'ai pris la décision de ne faire des tests qu'avec mes collègues pharmaciens.
Design haute-fidélité
v1
Le cadre applicatif déjà en place nous permet de concevoir facilement les interfaces finales de la fonctionnalité.
La toute première version utilise un composant stepper pour matérialiser la saisie :
- Des informations du BL
- Du contenu du bac réceptionné
Nous mettons en production et pouvons observer la courbe d'adoption.
Je n'ai plus accès à cette version du design.
v2
Rapidement, nous constatons 2 problèmes :
- Les données montrent que beaucoup de réceptions sont démarrées, mais jamais clôturées. Une enquête auprès des pharmacies indique que le stepper n'est pas compris.
- L'équipe technique demande à ce que l'on fusionne le parcours à une seule étape, plus simple à gérer techniquement.
Pour cette 2é itération, nous fusionnons le parcours, et introduisons un composant drawer, pour masquer les informations inutiles à l'instant T. Ce drawer sera beaucoup déployé dans les autres modules de l'application par la suite, pour la simplicité des parcours qu'il permet et pour la cohérence de l'expérience utilisateur.
Avec cette version, les réceptions sont correctement clôturées, problème résolu, mais...
Un pharmacienVotre système est bien, mais c'est trop lent comparé à mon logiciel actuel.
Tests comparatifs
La remarque du pharmacien porte sur l'absence de la fonction d'import du BL en CSV dans l'application. Lors d'un séjour à Abidjan, nous nous rendons dans une pharmacie pour un test comparatif en condition réelles.
Objectif : sur un cas en conditions réelles, comparer l'efficacité des parcours entre notre logiciel et celui utilisé par ce pharmacien, Easy Pharma, n°2 du marché.
Processus commun : Ouvrir un bac, déposer tous les produits sur la table de tri.
Réception Meditect
Avec Meditect, pour chaque référence :
- Scanner les boîtes, ce qui met à jour la quantité reçue
- Saisir la quantité commandée
- Vérifier que les prix sont corrects
A la fin, on contrôle le bilan financier de la réception. Et on valide, ce qui met à jour le stock.
Réception Easy Pharma
Pour chaque référence :
- Compter les boîtes
- Contrôler les informations avec le BL papier
Puis passer sur Easy Pharma :
- Charger le BL CSV dans le logiciel
- Contrôler les quantités et les prix
- Valider pour mettre à jour le stock
Sur le parcours total, nous sommes plus rapides !
Enseignements clés
- Admettre l'erreur pour progresser : Même si le stepper faisait sens, ne pas rester sur cet échec a permis de débloquer l'usage de la fonctionnalité. Plusieurs centaines de commandes sont aujourd'hui réceptionnées dans le logiciel, chaque jour.
- Faire d'une contrainte une opportunité d'amélioration : La demande de l'équipe tech de fusionner le parcours en une seul étape a finalement été l'occasion d'introduire le drawer et de proposer une UX efficace et cohérente partout dans l'ERP.
- S'en tenir au MVP : Valider le parcours core avant d'ajouter les facilitateurs. L'import CSV manquant semblait critique, mais le comparatif a prouvé que notre MVP était déjà plus rapide que le concurrent #2 du marché.
- Comparer le process complet : Ne pas s'en tenir à un retour sur une fonctionnalité manquante. C'est tout le process métier qui doit servir de comparaison pour juger de la performance du produit.