Transformation · Ce qui casse
Pourquoi les transformations échouent
« 70 % des transformations échouent » ouvre des présentations depuis trente ans, et presque personne ne peut dire d’où sort le chiffre. Mark Hughes, de l’université de Brighton, a repris cinq publications qui l’énoncent, a remonté la référence de chacune, et n’a trouvé sous aucune d’elles la moindre donnée empirique valide et fiable (Journal of Change Management, 2011, volume 11, numéro 4, pages 451 à 464). Cette page ne contient donc aucun taux d’échec. Elle décrit les mécanismes qui font retomber une transformation, tels que nous les avons vus fonctionner de l’intérieur.
D’où vient le chiffre que tout le monde cite.
La trace remonte à 1993. Dans Reengineering the Corporation, Michael Hammer et James Champy écrivent page 200 : « Our unscientific estimate is that as many as 50 to 70 percent of the organizations that undertake a reengineering effort do not achieve the dramatic results they intended. » Les auteurs qualifient eux-mêmes leur estimation de non scientifique, et elle porte sur le reengineering des années quatre-vingt-dix, une méthode précise avec ses propres conditions. Le chiffre a quitté ce cadre et s’est mis à désigner tout changement d’organisation. Hughes, dix-huit ans plus tard, a remonté la source de cinq publications qui l’affirmaient et a trouvé, au bout, d’autres articles citant d’autres articles. Il a survécu parce qu’il est commode : il justifie une ligne d’accompagnement dans un budget et il donne une raison d’appeler un cabinet.
Les gens qui savaient s’en vont avant l’ancrage.
Le budget d’un programme se termine à la mise en service, parce que c’est la ligne qu’on a fait voter. L’intégrateur dispose d’une garantie de quelques semaines, puis son contrat se referme et ses consultants partent sur le programme suivant. Les personnes qui connaissaient les paramétrages par cœur, celles à qui un chef de rayon envoyait un message et obtenait une réponse dans l’heure, travaillent ailleurs le mois d’après. Le système, lui, tourne toujours. Ce qui a disparu, c’est la capacité de l’ajuster.
Le sponsor part souvent lui aussi. Un programme vit dix-huit à vingt-quatre mois et un directeur reste rarement aussi longtemps sur le même périmètre ; quand il change de poste au milieu, son successeur hérite d’un projet qu’il n’a pas choisi, dont il ignore les arbitrages passés, et qu’il n’a aucun intérêt personnel à défendre au prochain comité budgétaire. Personne ne l’arrête. Les demandes d’ajustement s’empilent dans une file sans priorité, et un programme qui n’est plus porté ralentit avant de s’arrêter.
La formation et l’outil arrivent à côté du travail réel.
Les sessions de formation se calent sur les disponibilités des formateurs et des salles, souvent quatre à huit semaines avant la bascule, parce que c’est la seule fenêtre où tout le monde est libre. Entre la session et le premier vrai client, le logiciel a été livré deux fois de plus, des écrans ont changé, et le support montre une interface qui n’existe déjà plus. Les équipes retiennent alors la chose la plus mémorable de la journée, qui est presque toujours le déjeuner.
L’autre décalage vient du cahier des charges, écrit à partir de la procédure officielle, celle qui décrit comment le travail devrait se faire. Le travail réel contient des exceptions que ce document ne mentionne nulle part : le client qui rapporte un article sans ticket, la livraison scindée en deux camions à trois jours d’écart, l’article d’une gamme arrêtée qu’il faut quand même savoir réparer. Quand le système n’offre aucun chemin pour ces cas, le magasin en invente un, dès le premier mois. Chaque tableur parallèle est une réparation locale intelligente. Ensemble, ils forment un second système d’information que personne ne pilote.
L’ancien geste reste plus rapide, et plus personne ne regarde.
Une habitude se mesure en secondes. Un geste ancien prend vingt secondes parce que la main le connaît ; le même geste dans le nouvel outil en prend cinquante la première semaine, le temps de retrouver le bon écran et le bon champ. Sous pression, avec quatre personnes qui attendent, la voie la plus courte l’emporte, et elle a de bonnes raisons de l’emporter : la personne fait son métier. La nouvelle façon s’installe le jour où elle devient réellement plus rapide, ou le jour où l’ancienne est fermée techniquement, à une date connue de tous.
Le dernier mécanisme concerne le regard. Le tableau de bord d’adoption a été construit par le programme et hébergé par le programme, donc il meurt avec lui : l’accès expire, la personne qui l’actualisait est partie, le comité de pilotage ne se réunit plus. L’organisation dérive deux trimestres sans que personne ne le voie.
Ce qui a tenu sur 29 magasins.
Nous avons mené une bascule qui touchait 29 magasins le même jour, à l’échelle nationale, et le chiffre d’affaires n’a pas décroché. Côté magasins, environ 145 personnes changeaient d’outils et de gestes au même moment. Huit domain leaders portaient chacun un domaine de bout en bout : le paramétrage, la reprise des données, la formation des équipes concernées, puis les réponses aux questions dans les semaines qui ont suivi. Ces huit personnes étaient nommées, connues des magasins par leur prénom, et elles sont restées après la mise en service.
Une contrainte a produit plus d’effet que tout le reste. Une gamme était arrêtée et la garantie après-vente courait dix ans : il fallait qu’un conseiller puisse, une décennie plus tard, retrouver un produit qui ne se vendait plus, identifier la pièce et déclencher la réparation. Cette obligation a forcé une chose rare, celle de concevoir les données et le processus pour l’état stable qui viendrait ensuite, bien au-delà de la journée de lancement. Les 145 personnes ont été formées dans leur propre magasin, à leur propre caisse, et les huit domain leaders étaient joignables le samedi, qui est le jour où un magasin découvre ses vrais problèmes. Nous racontons cette période dans « Conduite du changement, ce qui tient après le lancement ».
Les signaux que nous regardons.
Nous demandons d’abord un nom. Une personne, dans l’organigramme d’aujourd’hui, dont le travail après la mise en service sera de traiter les demandes du terrain, de corriger les paramétrages et de mettre les nouveaux venus à niveau, avec un rattachement et une part de temps chiffrée. « On verra à ce moment-là » revient souvent, et cette réponse situe le risque à elle seule. Vient ensuite la date de fermeture technique de l’ancienne voie : tant qu’un ancien écran ou un fichier partagé reste accessible sans échéance, deux façons de travailler coexistent et les données des deux sont incomplètes.
Un samedi à seize heures, quelqu’un doit répondre. Dans les organisations où l’adoption tient, ce nom et le canal pour le joindre sont écrits avant le lancement. La mesure d’usage, elle, doit exister avant la bascule : trois semaines de relevé sur l’ancien fonctionnement créent le point de comparaison sans lequel aucune dérive ne se voit. Le dernier signal se compte. Dix exceptions réelles déroulées dans un vrai magasin, avec les personnes qui les traitent, en disent plus qu’un cahier de recettes de deux cents pages validé à distance.
Ce qui nous agace, pour être franc : le chiffre reste plus commode qu’une explication. Il tient sur une diapositive, il justifie un budget, il donne une raison de signer. Le remplacer par les six mécanismes qui font retomber une transformation demande dix minutes d’attention au lieu de trois secondes. Nous n’avons pas encore trouvé comment rendre cette réponse aussi facile à emporter que le pourcentage qu’elle remplace.
Notre page conduite du changement décrit la discipline telle que nous la menons, du cadrage jusqu’à la mesure d’usage à 90 jours. La part de présence auprès des personnes, celle qui se joue dans les allées et aux caisses, est détaillée sur accompagnement au changement, et quand la bascule touche les systèmes eux-mêmes, notre conseil en transformation digitale part des conditions de production.
Des questions, des réponses franches.
Est-il vrai que 70 % des transformations échouent ?
Ce taux n'a pas de source solide. Mark Hughes, de l'université de Brighton, a repris cinq publications qui l'énoncent et a remonté la référence de chacune (Journal of Change Management, 2011, volume 11, numéro 4, pages 451 à 464). Sa conclusion : le récit circule, sans donnée empirique valide et fiable derrière lui. La trace la plus ancienne mène à Reengineering the Corporation, de Michael Hammer et James Champy, 1993, page 200, où les auteurs qualifient eux-mêmes leur estimation de 50 à 70 % de « unscientific » et l'appliquent au seul reengineering.
Quelle est la cause d'échec la plus fréquente ?
L'absence d'un propriétaire nommé pour l'après. Le budget s'arrête à la mise en service, l'intégrateur referme son contrat après quelques semaines de garantie, et les personnes qui connaissaient les paramétrages partent ailleurs. Le système continue de tourner. La capacité de l'ajuster a disparu, et c'est elle qui fait la différence au troisième mois.
À quel moment une transformation retombe-t-elle ?
Pendant le trimestre qui suit la mise en service, rarement d'un coup. La chute se fabrique par tolérances successives : un contournement autorisé un jour de forte affluence, un tableur monté pour un cas que l'outil ne couvre pas, un manager qui laisse passer l'ancien circuit parce que la clôture presse. Chacune est raisonnable prise seule.
Comment savoir tôt si une transformation va tenir ?
Cinq éléments s'observent avant la bascule : un propriétaire nommé pour l'après avec une part de temps chiffrée, une date de fermeture technique de l'ancienne voie, une réponse claire sur qui traite une demande du terrain un samedi après-midi, une mesure d'usage démarrée avant le lancement, et le nombre d'exceptions réelles déroulées sur place.
Faut-il faire un pilote avant de généraliser ?
Un pilote répond à la question technique et laisse entière la question d'échelle. Un site pilote reçoit une attention que les autres n'auront jamais : le chef de projet passe, les demandes remontent vite, les équipes savent qu'on les regarde. Il sert donc à valider un paramétrage et à repérer les exceptions du métier.
Notre transformation est déjà retombée, que faire ?
Regarder d'abord où passe le travail réel aujourd'hui. Les équipes ont presque toujours construit un circuit parallèle pour les cas que le système ne prévoit pas, et ce circuit désigne exactement les lacunes à combler. Reprendre ces cas, nommer un propriétaire, fixer une date de fermeture de l'ancienne voie et remettre une mesure en place se compte en semaines.
Regardons votre bascule avant qu’elle parte.
Apportez la transformation qui vous occupe, celle qui démarre ou celle qui est déjà retombée. Trente minutes suffisent pour repérer lesquels de ces mécanismes s’installent chez vous, et ce qui se répare en premier.