La transformation digitale est un problème de design de service, pas de technologie

La transformation digitale tourne mal quand on la mène comme un programme technologique : choisir une plateforme, mettre les formulaires en ligne, compter les systèmes lancés. Le client retrouve les mêmes passages de relais, les mêmes pièces justificatives et la même attente, simplement sur un écran. Traitez-la plutôt comme un problème de design de service. Repensez ce que la personne cherche à accomplir, de bout en bout, sur scène et en coulisses, et seulement ensuite décidez de ce que la technologie doit faire.

La croyance, énoncée honnêtement

La croyance est la suivante : nos services sont lents parce que nos systèmes sont vieux. Remplaçons les systèmes, mettons les services en ligne, et l'expérience s'améliorera d'elle-même.

Ce n'est pas une croyance absurde. Les vieux systèmes ralentissent bel et bien les choses. Le papier se perd. Beaucoup de services sont réellement meilleurs en ligne, et certains ne peuvent passer à l'échelle qu'ainsi. Les dépenses technologiques sont en outre faciles à planifier, à approuver et à suivre. Elles ont des fournisseurs, des jalons et une date de lancement. Un comité de direction peut les voir avancer.

L'instinct de commencer par la technologie se comprend donc. Le problème, c'est ce qu'il laisse de côté.

Pourquoi cela échoue en pratique

On numérise le processus, pas le résultat

Le premier geste de la plupart des programmes consiste à prendre le formulaire existant et à le mettre en ligne. Chaque champ, chaque pièce jointe, chaque étape de signature survit au déménagement. Le client qui faisait la queue au guichet téléverse désormais les mêmes sept documents sur un portail, puis attend que les trois mêmes directions valident l'une après l'autre. Le service est numérique. Il n'est pas meilleur.

Les services traversent les directions ; les programmes, non

Un client vit un seul service : « renouveler ma licence », « ouvrir un compte », « inscrire mon enfant à l'école ». À l'intérieur de l'organisation, ce service passe par plusieurs directions, chacune avec son système, son budget et ses objectifs. Les programmes technologiques sont généralement découpés direction par direction : chaque partie est modernisée, et les jointures entre elles, là où se loge l'essentiel des délais, sont laissées en l'état.

Melvin Conway a observé en 1968 que les organisations tendent à produire des conceptions qui reproduisent leurs propres structures de communication. Les services numériques lui donnent raison chaque jour. Si trois directions ne se parlent pas, le portail aura trois rubriques qui ne se parlent pas non plus.

Personne ne conçoit les coulisses

L'écran que voit le client, c'est la scène. Derrière se trouvent les personnes, les règles, les validations et les systèmes qui produisent réellement le résultat. G. Lynn Shostack a décrit le service blueprint pour la première fois en 1982 et l'a fait connaître à un large public d'entreprise dans un article de la Harvard Business Review en 1984, précisément pour rendre visible cette partie cachée. La plupart des programmes de transformation conçoivent la scène dans le détail et laissent les coulisses telles quelles. Résultat : une application soignée posée sur un processus qui exige toujours la signature d'un responsable sur papier.

Le succès se mesure en livraisons, pas en changements

« Systèmes lancés », « services en ligne » et « taux de numérisation » sont des indicateurs d'activité. Ils peuvent tous progresser pendant que le délai d'obtention du résultat, le nombre de contacts répétés et le taux d'abandon stagnent. Quand le tableau de bord récompense les lancements, les équipes lancent. (Mesurer la bonne chose est traité dans Mesurer la transformation par les résultats, pas par l'activité.)

Ce qui fonctionne à la place

Faites du service, et non du système, l'unité de la transformation. En pratique, cela suppose cinq habitudes.

1. Nommez le résultat que veut la personne. Pas « déposer une demande », mais « avoir le droit d'ouvrir ma boutique ». Écrivez-le avec les mots du client. Cela fixe le périmètre du travail, et il est presque toujours plus large qu'une seule direction.
2. Cartographiez tout le service tel qu'il fonctionne aujourd'hui. Utilisez une carte d'expérience pour le voir du côté du client, puis un service blueprint pour voir les coulisses : qui touche au dossier, ce qu'il vérifie, ce qu'il attend. Faites vous-même la démarche ; ne la cartographiez pas à partir du manuel de procédures.
3. Interrogez chaque étape avant de la numériser. Pour chaque pièce, chaque validation et chaque champ, demandez : pourquoi est-ce là, qui s'en sert, et que se passe-t-il si on le supprime ? Les changements de règles et de processus sont généralement les améliorations les moins chères et les plus importantes, et ils ne coûtent pas une ligne de code.
4. Testez le nouveau service avant de construire le système. Faites tourner le parcours repensé à la main pendant quelques semaines avec un petit groupe, un test concierge, ou placez une interface simple devant des personnes qui font le travail manuellement, un test du magicien d'Oz. Vous apprenez ce que la technologie doit réellement faire, en général moins que ce que disait le cahier des charges.
5. Confiez tout le service à une seule personne. Nommez un responsable de service doté d'autorité sur les directions concernées, et mesurez le service à ce qu'obtient le client : délai d'obtention du résultat, nombre d'étapes, contacts répétés, abandons.

La technologie devient alors ce qu'elle devrait être : le moyen de rendre à grande échelle le service repensé, et non la refonte elle-même.

Un exemple

Illustratif. La municipalité d'une ville européenne de taille moyenne a mené un programme de trois ans pour « mettre en ligne les licences commerciales ». Le nouveau portail a été lancé dans les délais. Les demandes prenaient toujours à peu près le même nombre de semaines, et les appels au centre de contact ont augmenté, parce que les demandeurs ne savaient pas laquelle des quatre directions détenait leur dossier.

Une petite équipe a été chargée de reprendre le sujet. Elle a construit le blueprint d'un seul parcours, celui d'un gérant de café qui demande l'autorisation d'ouvrir, et a trouvé onze passages de relais entre l'urbanisme, l'hygiène et la santé environnementale, la sécurité incendie et le service des licences, chacun attendant que le précédent ait terminé. Trois des documents demandés étaient déjà détenus par une autre direction. Deux validations n'étaient successives que par habitude.

L'équipe a mené un pilote manuel sur un quartier : un seul agent responsable de chaque demande du début à la fin, des directions qui examinent en parallèle, et la suppression des documents en double. Le portail est resté, mais son rôle a changé : il montrait désormais au demandeur un seul interlocuteur et un seul statut. Le pilote a indiqué à la municipalité exactement quelles intégrations valaient la peine d'être construites et lesquelles étaient totalement inutiles.

À faire, à éviter

À faire

• Commencer par un seul service à fort volume, pas par toute l'organisation.
• Faire venir dans la salle les personnes qui rendent le service, pas seulement celles qui le pilotent.
• Construire le blueprint des coulisses avant d'écrire la moindre exigence technique.
• Traiter les règles et les procédures comme une matière de conception, pas comme des contraintes figées.
• Tester le nouveau parcours à la main avant de s'engager à construire.

À éviter

• Transposer un formulaire papier en ligne, champ par champ.
• Découper le travail par direction ou par système.
• Présenter « services numérisés » comme un succès.
• Laisser la forme du produit du fournisseur décider du fonctionnement du service.
• Confier la refonte à la seule DSI, ou au seul design de service. Il faut les deux, sous la conduite du responsable métier.

Les questions qu'on nous pose

Le design de service n'est-il que l'expérience client sous un autre nom ? Non. Le travail sur l'expérience client se concentre souvent sur ce que le client voit et ressent. Le design de service couvre cela et les coulisses : le personnel, les règles, les systèmes et les passages de relais qui produisent l'expérience. Dans une transformation, c'est dans les coulisses que l'essentiel du changement doit avoir lieu. Si vous hésitez entre les deux cartes, voyez Parcours client ou service blueprint ?

A-t-on encore besoin d'une feuille de route technologique ? Oui, mais elle doit suivre la refonte du service, pas la précéder. Une fois que vous savez comment le service doit fonctionner, la feuille de route décrit ce que les systèmes doivent faire pour le soutenir. Beaucoup d'organisations constatent que la liste raccourcit.

Par où commencer si tout est à revoir ? Choisissez le service qui a le plus de volume et le plus de réclamations, cartographiez-le de bout en bout, et corrigez d'abord les jointures entre directions. Un service bien traité en apprend davantage à l'organisation que dix à moitié faits. Avant de redessiner quoi que ce soit, il est utile de cartographier le système avant de le changer.

Pour aller plus loin

Cet article s'inscrit sous l'article principal de la rubrique, La transformation échoue à la porte du client. Pour le travail concret, commencez par le service blueprint et la carte d'expérience, utilisez une carte systémique pour voir quelles directions et quelles règles façonnent le service, et une matrice des points de contact pour voir chaque canal que traverse le client.