Comment rater son projet d’externalisation de données de santé en 6 étapes ? #4
Ne pas s’intéresser à la mesure de l’expérience utilisateur
« En migrant mes applications de santé chez un hébergeur HDS, au vue de la puissance des machines que j’ai commandée, cela ne pourra jamais être aussi pire que ce que j’ai aujourd’hui dans ma salle informatique. J’ai tout prévu, augmentation de la bande passante réseau, utilisation de baies de stockage avec disques ultra rapides, migration de la base de données en Oracle 19c. C’est sûr, ça va pulser ! Les tests applicatifs, une vraie usine à gaz. »
Il est acquis que les données manipulées par les systèmes d’information de santé hébergés se doivent d’être disponibles, intègres, confidentielles et traçables. L’accès à ces données se faisant pour la plupart du temps au travers de progiciels métiers, il est un indicateur particulièrement intéressant à mesurer : le taux de satisfaction des utilisateurs/usagers. Mais quand et comment le mesurer ? Après le projet d’externalisation, quoi de plus désagréable que d’entendre un refrain du type « c’était mieux avant », noircissant ainsi dès le départ la relation avec l’hébergeur ? Il est donc grand temps de s’intéresser à la mesure de l’expérience utilisateur et, autrement dit, de s’emparer du sujet de la performance applicative.
En effet, dans un contexte de cloudification massive, d’alignement d’indicateurs de suivi de l’expérience utilisateur et de digitalisation à tout-va des processus métier, il est devenu un enjeu pour tout type de structures de santé de pouvoir améliorer cette expérience au sens large : utilisateurs internes (personnels soignants, administratifs, techniques), vip, clients, fournisseurs, partenaires et bien évidemment patients.
En adoptant cette posture avant la migration du SIS, et avec l’aide d’outils de monitoring adaptés, les Directions Métier vont pouvoir disposer d’une photographie de l’existant : l’accès à mon DPI pour créer un dossier patient prend 8 secondes ! la page d’affichage du portail patient prend 3 secondes mais l’affichage se fait en séquence en commençant par le bandeau du milieu de la fenêtre, la requête BI pour connaître l’état de mes stocks de masques FFP2 plante une fois sur deux, …
C’est à ce stade qu’il apparaît le plus opportun de lancer de façon priorisée les chantiers de définition de parcours utilisateurs, de définition de KPIs métier (nombre de visiteurs par heure, nombre de commandes, nombre d’envoi de SMS/Mails pour une compagne marketing, consommation, …), de KPIs techniques (CPU/RAM/Stockage/IO Disque, temps de réponse, taux de disponibilité, …) et de remédiation technico-fonctionnelle auprès des éditeurs de logiciel et autres fournisseurs de service.
Bien évidemment, ces mesures sont également à effectuer lors des deux autres phases du projet de migration :
- Pendant la phase de BUILD où il sera possible d’effectuer encore certains ajustements dits qualitatifs. C’est surtout dans cette phase que sera adaptée la mise en place de l’arsenal technologique permettant d’effectuer les mesures : monitoring des ressources, tests de charge applicative via des robots (stress test), alerting, … Certains audits seront nécessaires : audit applicatif, audit de performance, audit réseau
- Pendant la phase de RUN où la surveillance continue des variations d’indicateurs devra permettre le trouble shooting applicatif en cas de sévères dégradations de performances ; il peut s’agir par exemple d’un dysfonctionnement d’origine temporelle lié à un surcroît d’activité (importation d’une mise-à-jour de catalogues de consommables santé tous les 2 mois, commande de gel hydroalcoolique, …) et qui se doit d’être corrigé surtout s’il a un caractère répétitif et saisonnier
Lors de chaque modification majeure de l’architecture, lors de chaque ajout d’une nouvelle application, il faudra s’assurer de la cohérence des indicateurs de performance applicative et, à tout le moins, s’assurer de la non-régression de la mesure de l’expérience utilisateur.
Conseil N°4 : Lancer un projet de mesure de l’expérience utilisateur avant, pendant et après la migration en HDS. Adoptez une approche par cas d’usage métier en se focalisant sur l’application la plus visible.