Toute demande utilisateur ou incident utilisateur est un frein dans la vitesse ou la qualité d’exécution de son travail.

Et son travail, de bout en bout, est au service de la stratégie d'entreprise.

Nous avons donc accès nos efforts vers le support utilisateur.

Support Utilisateur

Dans son travail quotidien nos utilisateurs vont utiliser plusieurs outils sur lesquels ils peuvent être avoir été mal formés, sans compréhension réelle de la procédure, sans connaissance des impacts d'une absence de données ou d'un mauvais renseignement.

Nous avons mis en place un cycle de production de documentation et de formation : toute demande ou incident lié à une méconnaissance d'un outil donne systématiquement lieu à la production d'une documentation, une entrée dans la faq de notre logiciel de ticketing. Si le manque de connaissance est ciblé sur un acte particulier alors une micro formation d'une dizaine de minutes est programmée pour réapprendre le bon geste.

La faq est inscrite dans le portail ticket iTOP et la formation est disponible sur un wiki (bookstack). Les utilisateurs sont libres de créer de nouvelles pages pour mieux s'approprier la documentation.

Dans le portail ticket, afin de mieux qualifier les demandes et les incidents, nous y avons décrit le catalogue de services que le service informatique peut fournir. Nous gagnons du temps dans la compréhension du besoin et nous répondons donc plus vite à l'utilisateur. Exemple de portail:

Itop permet de lier les incidents et leur résolution à des items informatiques, lors d'un incident sur ce même item, la résolution est immédiatement accessible. Aucune perte de temps dans la recherche d'une solution au problème.

Autonomie utilisateur

Un peu de vieux, un peu de neuf.

Certaines des procédures de notre ERP (gestion des tarifs /ex) sont très chronophages. Il fallait trouver un moyen de réduire ces temps de traitement. Cela implique de pouvoir accéder aux bases de données de l'ERP en lecture et en écriture, de fournir une interface utilisateur permettant l'extraction et/ou le chargement d'un tableur, un contrôle des fichiers, des données, etc, etc, etc.

Une des solutions serait de développer un spécifique dans l'ERP pour chacun des cas détectés. Beaucoup de temps et beaucoup d'argent à prévoir.

La solution appliquée est basée sur un ensemble de nouveaux outils qui ne s'intègrent pas directement avec l'existant, mais qui communiquent avec les anciens systèmes -transfert de données par SQL API, ...-.

• N8N, pour le traitement de données,
• Appsmith pour l'interface utilisateur.

Ces nouveaux outils permettent de développer des outils internes trois à dix fois plus rapidement.

Après analyse des tickets nous avons développé les fonctionnalités qui avaient le plus d'impact sur les process utilisateurs.

La mise en place de ces mesures, et le développement des outils internes, s'est étalée sur 6 mois.

Alors ? Quel est le résultat ?

Cette stratégie a permis de faire baisser la totalité des tickets de plus de 40%.

Il est difficile de mesurer l'impact direct de la documentation ou de la formation sur la performance de l'utilisateur, mais les applications internes qui ont été déployées sont massivement utilisées.

La baisse de tickets a aussi un impacte direct sur la fonction support, grossièrement cela représente 40% de temps "libéré".

Ce temps "libre" a été consacré à la montée en compétence technique de la personne en charge du support. L'escalade de niveau 2 a lieu moins fréquemment, elle est désormais susceptible de produire elle même de nouveaux outils internes avec une aide minimale.

En conclusion

Ok, les utilisateurs ont gagné en agilité, ils sont mieux informés et plus autonome, mais la DSI est elle devenu agile ?

A mon sens, ce n'est pas la mise en oeuvre de ce nouveau stack qui sera obsolète dans trois ans, ce ne sont pas toutes les pages de documentation créées qui rendent une DSI agile.

L'agilité n'est pas une fin en soi. Elle doit avoir un but.

C'est bien par la détection d'un besoin que nous avons réussi à combler que nous nous définissons comme agile.

Détecter le besoin -> Combler le besoin.

De cette simple petite flèche nous en déduisons qu'il nous faut être à l'écoute pour détecter ce besoin, et être rapide et simple dans la réponse.

De cette expérience j'en conclus ceci : une DSI agile n'est pas une réponse technique c'est un état d'esprit.

---

Références - lociels open source

• Gestion des tickets : iTOP, technologie CMDB, ITIL.
• Gestion de la documentation : BookStak, un wiki moderne et simple organisé en étagères, livres, chapitres, pages.
• Workflow Automation : n8n, a free and open fair-code licensed node-based Workflow Automation Tool.
• Développement d'outils internes : Appsmith, A powerful open source framework to build internal tools

Manifeste agile:

• Les individus et leurs interactions, de préférence aux processus et aux outils,
• Des solutions opérationnelles, de préférence à une documentation exhaustive,
• La collaboration avec les clients, de préférence aux négociations contractuelles,
• La réponse au changement, de préférence au respect d’un plan.