Ce cri du cœur des utilisateurs – qui aimeraient bien qu’on pense un peu à eux, à ce qu’on appelle nous, le « parcours client », et qu’ils appellent eux, parfois, « parcours du combattant » (comme expliqué ici) ou ‘l’effort client’ (comme expliqué là).

Et le cri du cœur des patrons qui en ont assez que les collaborateurs se plaignent que les systèmes soient lents, que « ça bug tout le temps », qu’ils aient le temps d’aller prendre un café entre chaque dossier « tellement ça mouline »…

Bref, une informatique chouette, c’est une IT pas pénible, et efficace.
Et si c’était aussi une informatique « waouh !!! » ???

Reprenons l’histoire du début

Dans une entreprise, l’IT est prise en main par les DSI, qui divisent, très justement, leurs activités en 2 :
– le build ou les projets dont la gestion est définie comme « tout l’opérationnel et le tactique qui font qu’un projet aboutit dans un triangle représentant l’équilibre qualité-coût-délai (QCD) »
– le run ou la production, qui « garantit le fonctionnement technique des moyens de production » (voir la définition de l’APEC).

Donc, en résumé, ce qu’on cherche à garantir dans l’IT c’est : la qualité (pas de bugs ?), le budget, les délais, éventuellement le périmètre, et limiter le nombre d’incidents et de questions.

Que ça soit sympa à utiliser ne fait pas vraiment partie de la liste, n’est-ce pas  ?
Vous me direz, si déjà on n’avait pas de bug, et que c’était livré dans les temps, on serait déjà content.
Oui, c’est vrai.
Mais est-ce que c’est ça de « l’IT WAOUH » ?

Que dit le Lean IT ?

Pour que ça soit chouette pour les utilisateurs, il faut déjà :

1. Écouter ce que disent les utilisateurs, et en particulier leurs plaintes, leurs réclamations.
De quoi se plaignent-ils exactement ? Sur quel sujet râlent-ils le plus ?
Comme l’explique Michael Ballé, expert du Lean : la réclamation client c’est un client qui prend le temps de nous dire ce qu’il veut, ce qu’il valorise vraiment, ce qu’il cherche à faire avec notre produit.
Pas la peine de se casser la tête à ajouter une énième fonctionnalité si « ça rame tout le temps », non ? Cela redonne clairement les priorités dans ce qu’il faut corriger et dans ce qu’il faut développer pour leur rendre la vie plus facile.

2. « Aller et Voir » et regarder comment les utilisateurs utilisent notre informatique.
On parle bien des vrais utilisateurs : les chargés de clientèle en agence, les gestionnaires au back office, les hôtesses de caisse à la caisse…
Il s’agit de voir par exemple qu’il faut ressaisir le numéro de sécurité sociale de l’assuré pour chaque remboursement de soin, qu’il faut changer de navigateur pour réussir à imprimer le contrat, ou recopier un numéro de suivi à 12 chiffres pour visualiser le trajet de son colis.
Et ça, c’est ballot. Parce que c’est souvent très simple à corriger. Et ça fait un effet « aaaaaaargggggggh ».
Et puis surtout, il s’agit de voir ce que les utilisateurs essaient de faire avec notre outil. Par exemple, on pense qu’ils s’en servent uniquement pour saisir des données. Mais en fait, cela leur sert aussi de formulaire à imprimer et distribuer. Et si le formulaire était joli, et bien ce serait plus chouette.

3. S’il s’agit d’un nouveau logiciel ou d’une nouvelle appli, le Lean Startup préconise le Minimum Viable Product (MVP), pour, justement, générer des retours (ou réclamations) des utilisateurs et avoir rapidement des moyens d' »aller et voir » pour s’améliorer et comprendre la valeur. Lire à ce sujet l’excellent article « Cake slice pattern ».

Mesurez-vous la satisfaction de vos client ? Connaissez-vous vos utilisateurs ? Et si c’était ça, l’effet « waouh » ?