Il y a eu un pilote réussi. La direction veut de la vitesse. La décision tombe : déployer vers le reste de l'organisation, d'autres équipes, d'autres services. Ce qui fonctionnait dans un coin doit maintenant fonctionner partout.
Cela ne se passe pas toujours bien, loin de là. Pas parce que la technologie réagit soudainement différemment, mais parce que l'environnement dans lequel elle doit fonctionner est organisé différemment partout. L'équipe où le pilote a réussi disposait, par hasard, d'une infrastructure informatique capable de répondre à ce qui était demandé, d'une gestion des données en ordre, et d'une structure organisationnelle où quelqu'un prenait ses responsabilités. Ailleurs dans l'organisation, une ou plusieurs de ces conditions sont différentes. Le résultat : le même effort donne quelque chose à un endroit et rien à un autre, ou pire, du travail supplémentaire pour réparer les erreurs.
Accélérer semble être l'étape suivante logique parce que le pilote a prouvé quelque chose. Il y a un résultat, il y a de l'enthousiasme, il y a une pression pour augmenter le rendement. Celui qui a réussi à faire fonctionner quelque chose ne veut pas se limiter à une seule équipe. De plus, accélérer est visible : plus d'utilisateurs, plus d'équipes, plus de lignes de processus qui adoptent la nouvelle façon de travailler. Cela ressemble à du progrès, même lorsque les dimensions fondamentales — organisation, infrastructure informatique, gestion des données — ne sont pas encore partout au niveau où la dimension qui en dépend peut, elle, fonctionner.
L'ordre dans lequel cela fonctionne n'est pas facultatif. Si la couche fondamentale n'est pas en place, la couche dépendante n'a rien sur quoi se construire. Ce n'est pas une question de préférence ou de prendre plus de temps ; c'est la manière dont les dimensions se portent mutuellement. Accélérer ignore cet ordre et s'attend à ce que la répétition d'une méthode de travail suffise, même sans le socle qui était présent la première fois par hasard.
Certains signaux reviennent souvent. Les équipes qui adoptent la nouvelle méthode de travail rapportent des résultats variables, et personne ne peut bien expliquer pourquoi cela fonctionne chez l'une et pas chez l'autre. On demande davantage de formation ou de communication, alors que le problème se situe ailleurs : dans des systèmes qui ne se connectent pas entre eux, dans des données qui n'ont pas la même qualité, dans une structure où personne n'est propriétaire du résultat au-delà des frontières entre équipes.
Est également reconnaissable la situation dans laquelle la technologie est déployée sur une structure qui n'a pas elle-même changé : la nouvelle méthode de travail est mise à disposition sur le plan technique, mais les rôles, les responsabilités et les lignes de décision restent les mêmes qu'avant le pilote. Comparable est le schéma dans lequel un pilote fonctionne bien dans son propre coin mais ne se connecte pas au reste de l'organisation : la mise à l'échelle copie la méthode de travail, pas les conditions dans lesquelles cette méthode de travail a été créée.
Un troisième signal est moins visible mais tout aussi déterminant : deux passionnés tirent la charrette et personne d'autre ne se sent responsable. Tant que l'initiative dépend de quelques personnes qui sont motivées par hasard, il n'y a pas de base organisationnelle pour accélérer — il n'y a que de l'enthousiasme qui ne se multiplie pas lorsque l'équipe s'agrandit.
Quiconque reconnaît ces signaux ferait bien de se demander si la dispersion entre équipes est le résultat de l'exécution, ou d'une différence de maturité déjà présente avant même le début de l'accélération. Cette distinction est précisément ce que la mesure de maturité de hybridresourcing examine : non pas un score unique pour l'ensemble de l'organisation, mais cinq niveaux répartis sur sept dimensions, mesurés en faisant évaluer plusieurs personnes séparément et en rendant visible la dispersion entre leurs réponses. Cette dispersion en dit souvent plus que la moyenne : si l'estimation du CEO diffère fondamentalement de celle du CIO, une partie de l'explication de pourquoi l'accélération fonctionne à un endroit et pas à un autre se trouve là. Ce qu'un CEO révèle dans cette mesure sur sa propre organisation et ce qu'un COO y reconnaît depuis l'exécution quotidienne donnent rarement la même image, et cette différence est précisément ce sur quoi la mesure est construite.
Cette page traite de la question de savoir si l'organisation peut porter l'IA : la structure, l'infrastructure, la gestion des données sont-elles à un niveau où accélérer a du sens. C'est une question différente de celle de savoir quelle partie du travail lui-même est adaptée pour être transférée à l'IA. Cette dernière question, c'est le scan de travail de FTE TO AI qui y répond : il calcule, par tâche, quelle partie du travail peut être reprise par l'IA, indépendamment du fait que l'organisation soit déjà prête ou non. Les deux questions vont de pair, mais l'ordre n'est pas facultatif — savoir ce qui est transférable a peu de valeur tant qu'il n'est pas établi que la base peut porter ce transfert.
La mesure de maturité de hybridresourcing est encore en construction. Ceux qui souhaitent utiliser la mesure dès qu'elle sera disponible peuvent s'inscrire sur la liste d'attente.
Vraag maar wat er moet staan voordat AI in uw organisatie kan landen.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.