On achète un outil d'IA, on l'implémente, on le déploie. Il y a un budget, il y a un fournisseur, il y a une date de démarrage. Ce qui n'existe pas : un changement dans qui prend quelle décision, comment l'information circule entre les services, ou où se situe la responsabilité lorsque le résultat du système diffère de ce qu'un collaborateur attendait. L'organisation reste exactement telle qu'elle était, avec une couche de technologie ajoutée par-dessus.
L'hypothèse est que la technologie fait le travail et que la structure peut rester inchangée. Cela vaut pour une calculatrice. Cela ne vaut pas pour un système qui a besoin de données provenant de trois services qui se parlent déjà mal entre eux, ou qui propose une décision à quelqu'un qui n'a pas le mandat de prendre cette décision.
Acheter une technologie est une action concrète et bien délimitée. Il y a un devis, une date d'implémentation, un résultat qui devient visible sur un tableau de bord. Changer la structure est vague : qui va faire cela, quand ce sera terminé, quel en est le résultat. Entre une action claire et une action floue, une organisation choisit presque toujours l'action claire.
À cela s'ajoute le fait que les fournisseurs de systèmes d'IA vendent leur produit comme quelque chose qui s'adapte à l'organisation existante. C'est aussi leur modèle économique : moins le client doit changer, plus la vente est facile. Le message selon lequel l'organisation doit d'abord elle-même changer quelque chose ne trouve pas sa place dans cette conversation commerciale.
Et il y a une troisième raison, peut-être la plus importante : changer la structure touche au pouvoir, à qui décide maintenant et qui décidera demain. Acheter une technologie n'y touche pas. Il est plus facile d'acheter que de reconsidérer qui porte quelle responsabilité.
Un certain nombre de signaux qui apparaissent plus souvent ensemble que séparément :
La technologie est en place, mais personne n'a reçu l'autorité d'agir différemment qu'auparavant sur la base du résultat. Le système conseille, l'humain décide comme il l'a toujours fait, et le conseil disparaît dans un tiroir.
Les données dont le système a besoin sont dispersées entre des services qui n'ont pas de processus commun pour les partager. Le système fonctionne avec ce qu'il reçoit par hasard, et la qualité du résultat dépend de quel service a fourni des données cette semaine-là, par hasard.
Il y a une équipe pilote enthousiaste, mais le reste de l'organisation continue de travailler comme avant. Ce qui manque précisément dans ce cas, vous le lirez dans la description d'un pilote qui reste bloqué avec deux enthousiastes et personne d'autre.
Le pilote a démarré sans qu'il ait été défini ce que signifie le succès et qui l'évalue. Après quelques mois, il y a un résultat, mais personne ne sait si ce résultat est suffisamment bon pour continuer. Ce schéma est décrit dans un pilote qui se déroule sans critères convenus au préalable.
On décide d'étendre le déploiement alors que le premier pilote fonctionne encore avec des exceptions et des corrections manuelles. Ce qui se passe alors est décrit dans passer à l'échelle avant que la base ne soit établie.
Et la technologie fonctionne bien au sein d'une seule équipe, mais dès que le résultat nécessite une autre équipe pour avancer, le processus se bloque. C'est le schéma d'un pilote qui ne fonctionne que dans les limites de sa propre équipe.
Si deux ou plusieurs de ces signaux se manifestent, il est probable que la technologie prenne en charge une tâche que l'organisation ne s'est pas préparée à lui confier.
La mesure de maturité de hybridresourcing examine sept dimensions, dont trois sont fondamentales : l'organisation, l'infrastructure informatique et la gestion des données. Ces trois-là passent avant les autres, non pas parce qu'elles seraient jugées plus importantes, mais parce qu'une organisation sans flux de données fonctionnels et sans responsabilités claires n'a pas de base sur laquelle les autres dimensions peuvent s'appuyer. Cinq niveaux, du niveau de base à l'intelligence, indiquent où se situe une organisation sur chaque dimension.
Ce qui rend cette mesure particulière, c'est la ronde de positionnement : plusieurs personnes au sein de la même organisation évaluent séparément, sans s'influencer mutuellement. La dispersion qui en résulte est souvent plus riche en informations que la moyenne. Si le PDG situe l'organisation au niveau insight et le responsable informatique au niveau de base, cette différence est elle-même un signal, et précisément le type de signal qui est indépendant de la technologie achetée.
Ce à quoi un PDG prête particulièrement attention lors de cette mesure, et pourquoi cela diffère de ce qu'un COO juge important, est détaillé sur les pages ce à quoi un PDG prête attention en matière de maturité IA et ce à quoi un COO prête attention en matière de maturité IA.
Cette mesure porte sur la question de savoir si l'organisation peut porter l'IA, pas sur celle de savoir quel travail l'IA pourrait reprendre. C'est une autre question, avec un autre instrument. Une fois qu'il est clair où se situe l'organisation sur les sept dimensions, et quelles étapes fondamentales doivent encore être franchies, la question de savoir quelle part du travail est effectivement transférable à l'IA devient pertinente. Cette question, c'est le scan de travail de FTE TO AI qui y répond, en calculant par tâche quelle part peut être reprise. L'ordre n'est pas fortuit : d'abord la capacité de portage, puis la reprise.
La mesure de maturité de hybridresourcing est en cours de construction. Ceux qui souhaitent utiliser la ronde de positionnement 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.