Pourquoi le support après mise en production échoue, et comment savoir si c’est votre cas

Le projet se termine dans les délais. Le comité de pilotage reçoit sa dernière diapositive au vert et le partenaire d’implémentation est remercié dans un e-mail adressé à tout le personnel. Six semaines plus tard, la finance tient un tableur parallèle pour la clôture mensuelle, deux personnes de l’entrepôt se sont remises à téléphoner au bureau, et personne ne s’est connecté au portail client dont vous avez payé le paramétrage. Rien n’est cassé. Le système tourne, les intégrations fonctionnent, le rapport de disponibilité est irréprochable. L’organisation fonctionne simplement moins bien qu’au cours du dernier mois du projet.

Quand cela arrive, le réflexe est de regarder le logiciel. Ce n’est presque jamais le logiciel. La plus grande menace pour une mise en production ERP ou CRM est organisationnelle : qui est responsable du processus une fois l’équipe projet dissoute, où se trouve la connaissance, et ce qu’il advient d’un problème la troisième fois qu’il apparaît. Les systèmes tombent en panne avec fracas et sont réparés. Les organisations défaillent en silence et sont contournées. Un contournement, contrairement à une panne, ne déclenche jamais d’alerte. Voici les six schémas que nous rencontrons le plus souvent dans les entreprises belges et néerlandaises de taille moyenne, et une courte liste de signaux d’alerte à confronter à votre propre situation.

Le support après mise en production est vendu comme une phase, pas construit comme une capacité

Les contrats d’implémentation prévoient presque toujours une période d’hypercare : une période d’attention renforcée après la mise en production, généralement comptée en semaines plutôt qu’en mois. Elle est utile, et ce n’est pas du support. C’est la fin d’un projet, assurée par des gens du projet, chiffrée dans le budget du projet. Quand elle se termine, ce qui la remplace est généralement présenté comme le fonctionnement courant : une expression qui, en pratique, signifie que personne n’a rien décidé. La demande ne s’arrête pas à la fin de l’hypercare ; elle change de forme. Les premières semaines sont dominées par des personnes qui ne trouvent pas un bouton. Du deuxième au sixième mois arrivent les questions qui coûtent vraiment de l’argent : la clôture dont les rapprochements ne tombent plus juste, la règle de prix qui se comporte différemment pour un groupe de clients, le flux intragroupe que personne n’a testé parce que l’acquisition a été finalisée tard. Celles-là demandent quelqu’un qui comprend le métier, et elles arrivent précisément au moment où les personnes qui le comprenaient ont été libérées.

Le contexte part avec le partenaire d’implémentation

Pendant une implémentation, un petit groupe accumule une quantité énorme de connaissances non documentées. Pourquoi le contrôle de la limite de crédit intervient avant la confirmation de commande plutôt qu’après. De quels champs des données maîtres client l’interface logistique dépend réellement, par opposition à ceux dont elle dépend selon la spécification. Pourquoi l’entité néerlandaise porte une exception dans sa détermination des taxes. Presque rien de tout cela n’est écrit, parce que pendant toute la durée du projet, tous ceux qui en ont besoin sont dans la même pièce. À la passation, les livrables sont des documents : classeurs de paramétrage, scripts de test, supports de formation, une matrice des autorisations. Ils décrivent ce que fait le système. La connaissance qui coûte cher, c’est pourquoi il le fait de cette façon, et le pourquoi ne figure pas dans la liste des livrables. Quand le partenaire se retire, cette connaissance quitte le bâtiment, et contrairement à un document manquant, vous ne pouvez pas remarquer son absence avant le jour où vous en avez besoin.

Un service desk qui sait réinitialiser un mot de passe mais pas lire un workflow

Le support est souvent acheté sous forme de service desk : facturé par utilisateur ou par ticket, assuré par des personnes formées au comportement générique du logiciel plutôt qu’à votre paramétrage. Dans son périmètre, cette équipe est compétente. Problèmes d’accès, licences, impression, un rapport qui ne renvoie rien, un utilisateur à qui il faut ajouter un rôle. Tout est traité, et vite. Puis arrive un ticket signalant que depuis mardi, les commandes d’un groupe de clients reprennent les mauvaises conditions de livraison. Ce n’est pas une question de logiciel. C’est une question sur une condition de prix, une modification des données maîtres client et une règle d’expédition qui interagissent dans votre processus order-to-cash, et y répondre correctement demande quelqu’un qui sait comment ce processus est censé fonctionner. Un service desk générique va le router, l’escalader, puis finir par le clôturer avec une correction manuelle. La correction manuelle devient alors le processus, et personne ne l’enregistre comme un échec puisque le ticket a été clôturé dans le respect de son niveau de service.

Quelqu’un est responsable du système. Personne n’est responsable du processus.

Presque toutes les organisations désignent un responsable du système après la mise en production, généralement à l’IT. Son périmètre : disponibilité, mises à jour, autorisations, intégrations et coûts. Tout cela est nécessaire, et rien de tout cela ne dit si l’order-to-cash ou le procure-to-pay fonctionnent réellement de bout en bout. Les processus métier traversent les départements ; la responsabilité du système, non. Quand le défaut se situe entre les ventes et la logistique (et c’est généralement là qu’il se situe), personne n’a pour mission d’arbitrer, alors chaque département construit sa correction locale et l’écart entre eux se creuse. Dans une entreprise du Benelux de 200 personnes, c’est plus aigu que dans un groupe de 5 000, parce qu’il n’y a pas de bureau des processus sur lequel s’appuyer ni de capacité disponible pour en inventer un. La responsabilité revient par défaut à l’utilisateur clé qui se plaint avec le plus d’insistance, en plus du travail qu’il faisait déjà. Ce n’est pas un modèle de gouvernance, et il ne survit pas au changement de poste de cette personne.

Les files de tickets mesurent la vitesse de clôture, pas la récurrence

Les contrats de support se mesurent au temps de réponse et au temps de résolution. Les deux sont faciles à compter, faciles à présenter, et aucun ne vous dit si la même défaillance reviendra le mois prochain. Une file optimisée pour la vitesse de clôture préférera systématiquement le contournement à la correction, parce que le contournement prend vingt minutes et clôt le ticket, alors que la correction demande une discussion sur le processus, un cycle de test et une fenêtre de changement. Le chiffre qui vous apprendrait quelque chose, c’est la part des tickets du mois qui sont des récurrences d’un problème déjà vu. Peu d’organisations le mesurent, parce que cela suppose de classer les tickets par processus métier concerné plutôt que par module auquel ils ont été rattachés. Celles qui commencent à le mesurer sont en général mal à l’aise avec la réponse : un petit nombre de défauts de processus sous-jacents qui génèrent une part disproportionnée du volume, en silence, depuis des années.

Chaque incident récurrent est un défaut de processus qui porte un numéro de ticket.

Rien n’oriente un incident récurrent vers une correction définitive

C’est la défaillance qui contient les cinq autres. Même là où la connaissance survit et où quelqu’un est responsable du processus, la plupart des organisations n’ont aucun mécanisme qui transforme un « ça recommence » en un changement effectivement réalisé. Les incidents vivent dans un outil de service desk. Les changements vivent dans un portefeuille de projets qui ne s’ouvre qu’au moment d’un cycle budgétaire. Entre les deux, il y a un vide, et les problèmes récurrents y tombent pour de bon. La voie de sortie n’a pas besoin d’être sophistiquée. Elle doit être courte et sans surprise. Une revue mensuelle des incidents répétés, regroupés par processus. Une personne désignée, avec l’autorité de qualifier un problème de défaut de processus plutôt que d’erreur utilisateur. Et un budget permanent pour les corrections trop petites pour être des projets, parce que sans ligne budgétaire, chaque amélioration doit se justifier comme s’il s’agissait d’une nouvelle initiative, et aucune ne franchit jamais ce seuil.

Les signaux d’alerte à vérifier cette semaine

Aucun de ces signaux, pris isolément, ne prouve que votre support est défaillant. Trois ou quatre réunis, en général, si.

• Vos utilisateurs clés répondent à plus de questions que votre service desk, et cela ne figure nulle part dans leur description de poste.
• Des tableurs sont réapparus pour une étape que le système devait reprendre.
• Vous pouvez nommer la personne responsable de l’ERP ou du CRM, mais pas celle qui est responsable de l’order-to-cash.
• Vous savez dire quels modules génèrent le plus de tickets, mais pas quels processus métier.
• La réponse honnête à « pourquoi est-ce paramétré ainsi ? » est que le consultant l’a configuré de cette façon.
• Les supports de formation décrivent encore le processus tel qu’il a été conçu, pas tel qu’il est réellement appliqué aujourd’hui.
• Les changements n’arrivent que lorsqu’un nouveau projet est financé ; rien ne s’améliore entre deux projets.
• Les trois dernières corrections urgentes étaient des contournements temporaires, et les trois sont toujours en place.

Ce dont un support après mise en production efficace a vraiment besoin

Ce n’est pas plus d’heures, et c’est rarement un service desk plus grand. C’est un petit nombre d’éléments structurels. Un responsable de processus désigné côté métier pour chaque flux de bout en bout, avec l’autorité de trancher entre départements. Un support assuré par des personnes qui ont lu votre processus, pas seulement le manuel de l’éditeur. Un journal des décisions hérité de l’implémentation et tenu à jour au fil des changements de paramétrage. La récurrence mesurée à côté du temps de résolution. Et un chemin permanent de l’incident répété vers la correction définitive, assorti d’un budget modeste pour que les petites améliorations n’aient pas à rivaliser avec les projets d’investissement.

Cette capacité peut être construite en interne ou achetée à l’extérieur, et pour la plupart des entreprises de taille moyenne du Benelux, elle finit par être un peu des deux : la responsabilité des processus en interne, des ressources externes pour le paramétrage, le développement et le travail d’intégration délicat. Ce qui ne fonctionne pas, c’est de l’acheter après coup, à un prix fixé par le volume de tickets, auprès du moins cher une fois le budget du projet dépensé. Le meilleur moment pour concevoir le support après mise en production, c’est avant la mise en production, tant que vous avez encore du poids face à votre partenaire et que la connaissance est encore dans la pièce. Le deuxième meilleur moment, c’est maintenant. Commencez par relire les signaux d’alerte et par reconnaître honnêtement combien d’entre eux vous sont familiers.