Notre expérience dans l’accompagnement en Lean Management d’équipes support (principalement dans un contexte IT, pour ma part) au sein de grands groupes nous offre une lecture particulière de la situation.

Ces grandes entreprises (probablement toutes) ont créé – sur un même moule de bonnes pratiques – des systèmes dédiés aux incidents que rencontrent les utilisateurs internes et les clients finaux. Ces systèmes dédiés s’appuient sur des processus d’entreprise pour gérer (nous parlons bien ici de gestion de stock, qui est l’un des 7 gaspillages en Lean) des incidents / problèmes plus ou moins conformes au référentiel ITIL ou à la norme ISO 20000. Ces organisations passent la très grande majorité de leur temps à entretenir les processus et à exécuter des procédures pour débloquer (corriger) les clients, mais très peu d’énergie à supprimer définitivement (résoudre) les problèmes. Des audits internes sont également diligentés par la direction pour s’assurer que l’ensemble des parties prenantes respecte les processus établis par l’organisation. Mais combien de ces audits s’intéressent réellement aux clients qui subissent ces incidents ? De mon expérience, peu puisque leur finalité est d’obliger toutes les équipes à appliquer, le petit doigt sur la couture du pantalon, les processus corporate.

Ces organisations sont victimes de « la maladie des grandes entreprises », comme nous l’expliquent Michael Ballé, Daniel Jones, Jacques Chaize & Orest Fiume dans La Stratégie Lean :

c’est-à-dire le déplacement de l’attention des clients vers les problèmes internes (problèmes bureaucratiques qui s’imposent au travail réel des collaborateurs et autosatisfaction entraînant des investissements inutiles et des choix déterminés par le maintien du statu quo)

Des processus qui ne s’occupent pas des clients

Outre la gestion du stock de problèmes remontés par les clients finaux et les utilisateurs internes, le respect des procédures d’escalade vers les niveaux supérieurs (qui, d’un point de vue du client, ne résolvent en rien sa situation mais augmentent, parfois considérablement, son délai d’attente), la gestion de la base de procédures qui peut se chiffrer en centaines, voire milliers d’enregistrements (parfois incompréhensibles et ne permettant pas à un technicien lambda de savoir si ce qu’il fait est OK ou KO), on trouve dans les priorités de ces entreprises la «qualité des données» saisies par les personnes passant leurs journées aux téléphones avec des clients (internes ou finaux) mécontents, parfois en colère.

Certes, l’idée n’est pas mauvaise en soi et elle répondait certainement, à un moment ou un autre, à un problème spécifique. Ce dont on s’aperçoit, c’est qu’au fil du temps les règles à respecter pour avoir une bonne «qualité des données» sont de plus en plus complexes et nombreuses. On y trouve de tout : orthographe, respect des procédures, respect des données à saisir, choix de critères parmi des listes de plusieurs dizaines d’items à 2 ou 3 niveaux de profondeur…

Il n’y a aucune limite dans la capacité des processus à surcharger le système – donc dégrader l’environnement de travail des équipes support et augmenter les délais de correction – en ajoutant des données (bien évidemment obligatoires) pour au mieux pouvoir réaliser des pseudo-statistiques sur la typologie et l’origine (métiers, applications, modules…) des incidents rencontrés par les clients. Ces tableaux de bord déclenchent de temps en temps des actions coup-de-poing pour réduire – parfois artificiellement (si, si, c’est du vécu) – ce nombre.

Julia de Funès écrit dans son livre Socrate au pays des process :

[…] l’esprit doit être le premier, le process second, et non l’inverse. Sans quoi nous serions sous tutelle, c’est-à-dire dans l’incapacité de nous servir de notre entendement sans la conduite d’un autre. Or, si le tuteur d’une plante l’aide à grimper et à grandir par elle-même, le tuteur [NDLR : le processus] de l’homme peut l’empêcher de grandir en le maintenant dans l’enfance.

et d’ajouter :

La pensée élargie [NDLR : esprit qui n’est pas sous tutelle] donne ainsi, et de manière substantielle, du recul, c’est-à-dire du sens à nos actions, ce dont nous prive définitivement le process.

Toyota, au-delà des processus de l’entreprise, s’appuie sur des standards (lire Considérez le standard comme un kata, pas comme une règle de Marc Legru (traduction d’un article de Michael Ballé) et «n’a jamais fait du travail standardisé un outil de gestion imposé de force aux employés.» Les standards sont «un moyen de responsabiliser les opérateurs et de stimuler l’innovation.» (Le Modèle Toyota, 14 principes qui feront la réussite de votre entreprise, J. Liker)

Henry Ford – même si son système a fini par devenir rigide à cause de la bureaucratie – exprimait en 1926 sa vision des standards qui rejoint celle de Toyota :

La standardisation d’aujourd’hui… est la fondation indispensable de l’amélioration de demain. Si vous concevez la «  standardisation  » comme le summum des connaissances du jour mais qui doit être amélioré demain – vous avancez. Mais si les standards sont perçus comme un carcan, on ne progresse plus.

Comment travaillent-il ?

Mais, avez-vous pris le temps, un jour, de vous asseoir à côté d’un opérateur d’une équipe support pour

• voir les difficultés de son travail ;
• prendre conscience de la vitesse à laquelle cette personne doit saisir des informations que lui donne son interlocuteur parfois excédé par la situation ;
• dénombrer les champs saisis qui permettent vraiment d’apporter de la valeur au client (pour résoudre son problème) et ceux qui ne servent qu’à justifier l’activité support (aucune valeur pour le client) ;
• comprendre si le système informatique mis à disposition de cette personne est optimisé pour l’aider dans son travail. A-t-il été pensé avec des personnes des équipes support ? Peuvent-elles influer sur l’ergonomie et les usages ?
• vérifier si la base de procédures est équipée d’un moteur de recherche full-text (comme le proposait Apache Lucene). Les opérateurs expérimentés ont-ils la possibilité de modifier les procédures opérationnelles ou seules 2, 3 personnes autorisées ont-elles ces droits ?
• vous assurer que les processus de gestion des incidents / problèmes sont définis pour réduire au minimum le temps de résolution du problème rencontré par l’utilisateur / client. Sont-ils au service de l’équipe support ou l’équipe est-elle au service des processus ?
• vérifier que l’opérateur a tous les moyens (outils et connaissances) pour traiter (à défaut de résoudre) l’incident dans les meilleurs délais pour le client. Est-il obligé d’escalader au niveau supérieur parce qu’il n’a pas les droits sur une application particulière (serait-il moins intelligent que d’autres ?) alors que s’il les avait la correction ne prendrait que quelques minutes / heures versus jours / semaines / mois quand c’est escaladé ?
• …

Dans certaines entreprises, les équipes support sont parfois considérées comme des équipes à tout faire ; d’autant plus qu’elles sont au contact des clients. J’ai vu plusieurs fois des équipes projet s’appuyer sur des équipes support pour faire tester par des utilisateurs internes la nouvelle version applicative alors que le stock d’incidents ne faisait que croître… L’intention de départ est bonne, mais pourquoi ces équipes projet ne s’adressent-elles pas directement aux utilisateurs au lieu de passer par le support ? Peur de se confronter à la réalité ? Peur de découvrir que les utilisateurs ne sont toujours pas contents de l’application ?

Sans compter, qu’assez souvent, les équipes support sont les dernières informées qu’une nouvelle version a été mise en production. Elles le découvrent alors par les utilisateurs qui les appellent…

Par la non-résolution des incidents, les entreprises laissent augmenter le nombre d’incidents et mettent en place (par facilité ?) un système pour les gérer au lieu de les résoudre à la source. En effet, en ne portant plus l’attention sur les attentes de leurs clients et ne faisant pas de la qualité un vrai critère discriminant, elles favorisent l’émergence de défauts à la source venant alimenter sans cesse la base de procédures (nouvelles procédures pour gérer les nouveaux incidents) et le stock d’incidents. Certaines entreprises, pour éviter le pire, en viennent à vouer un culte tout particulier aux «pompiers de services» qui passent leur temps à éteindre les incendies pour sauver le projet, le programme, voire plus… Mais est-ce une situation acceptable ?

Se confronter au terrain

En tant que client final, est-il normal que je doive appeler un support pour :

• comprendre pourquoi lors d’un virement supplémentaire (en plus du virement mensuel programmé) vers un LDD, je vois apparaître 3 lignes sur mon suivi de compte : 1 pour le virement supplémentaire, 1 pour annuler le virement supplémentaire et 1 troisième pour renommer le virement supplémentaire dans un nom spécifique à la banque (sic !) ? Un bel exemple d’exposition au client de la complexité technique de la solution.
• informer les équipes support d’un hypermarché en ligne, que depuis deux semaines, il est impossible de sélectionner une ancienne commande pour en créer une nouvelle ? La réponse : «Mille excuses pour la gêne occasionnée. Notre équipe technique est actuellement sur le pont ! Merci pour votre compréhension.». Eh bien, non, en tant que client, je n’ai pas envie de comprendre, car ce n’est pas la première fois que je rencontre ce problème. C’est un véritable irritant qui peut se traduire par une perte du client.

Dans les 2 cas ci-dessus (réels), on parle de plusieurs millions de clients ; on imagine aisément le nombre d’appels au support…

En tant qu’utilisateur interne des systèmes d’information d’une entreprise, est-il normal d’appeler le support :

• pour changer son mot de passe, car l’intranet pour le modifier n’est pas si facile d’usage – contrairement à ce que tout le monde pensait tant que personne ne s’assoit à côté de l’utilisateur pour comprendre son utilisation ?
• pour faire modifier en base de données les valeurs du stock du magasin, car des clients ne peuvent emporter leur commande payée (!) alors que le vendeur leur avait assuré qu’il y avait du stock (l’inverse existe également…) ?
• pour faire ré-ouvrir un ticket qui a été automatiquement clos par le système car l’utilisateur (un vendeur dont la principale activité est de vendre et pas d’attendre d’être contacté par le support) n’était pas disponible pour valider la correction ?
• pour connaître les raisons du rejet d’un fichier de donnés XML dans un système qui ne retourne à l’utilisateur que OK ou KO (sans détail aucun, alors que les logs du SI contiennent toutes les informations relatives aux erreurs de format) sous prétexte que c’est au client de valider le format de son fichier ?
• pour savoir où en est la résolution du problème que l’utilisateur a remonté au support il y a déjà 2 semaines ?

D’aucuns diront que ces exemples sont caricaturaux ; pourtant, je les constate quasiment partout…

Résoudre définitivement

Comme l’écrivent Marie-Pia Ignace, Christian Ignace, Régis Médina et Antoine Contal, les auteurs du livre La pratique du lean management dans l’IT,

Le premier objectif d’un centre d’appels lean est de résoudre la demande du client. Puis de la résoudre le plus rapidement possible. Et enfin, de faire en sorte qu’elle soit résolue définitivement afin que le client n’ait plus besoin de faire cette demande.

Nous constatons à chaque fois que nous accompagnons une équipe support, qu’elle et son management sont concentrés sur le respect des processus de l’entreprise et qu’ils ne s’occupent quasi plus du client (ou si peu). Avec le Lean, les équipes (ré)apprennent à écouter de nouveau leurs clients (c’est-à-dire comprendre leurs attentes), à comprendre la situation actuelle, à déterminer et mettre en place les actions – au travers de PDCA – pour répondre efficacement (ce qu’on appelle le One Call Solution), le plus rapidement possible.

Une fois la «vitre nettoyée», il est possible de passer à la suppression des problèmes (lire La réduction des incidents informatiques, une priorité pour les grandes banques européennes de Pierre Jannez) pour ne plus avoir à gérer le flux entrant et éviter ainsi aux clients de devoir appeler un centre d’appels. Ainsi, de plus en plus de temps est libéré pour les personnes du support et ces dernières vont pouvoir aider l’entreprise à créer de la nouvelle valeur pour ses clients. La finalité est de réduire la charge de RUN pour augmenter la valeur du BUILD.

Quelques exemples de résultats

     

Autre exemple de ce qu’une équipe support IT peut faire avec le Lean Management et quand on lui donne les moyens : Une équipe améliore sa qualité de service de 83 % en huit mois.

Et vous, quelles sont vos dernières actions pour aider les équipes support et pour supprimer définitivement les incidents au lieu de les gérer ?