"Ambassadeur", "Champion", "Power Users", "M. Mme M365" : faisons le point !

Dans le dispositif de mise en place de Microsoft 365 en général et de SharePoint en particulier, j'ai généralement dû constater que l'approche "Projet" était utilisée par mes clients, que les principes de gouvernance qu'ils souhaitaient appliquer se limitaient généralement à former :

• Des administrateurs techniques dont la mission est de rendre opérationnel l'accès (utilisateurs, licences et permissions),

• Les utilisateurs Membres et les Propriétaires, la typologie d'utilisateurs que l'on retrouve sur MS Teams.

Avec cette approche, sur la durée et l'échelle, l'adoption des utilisateurs n'est généralement pas au rendez-vous et les échecs sont plus courants que les succès : au cours de ma session au MWCP22, j'avais argumenté ce constat en utilisant une étude de Skyhight Network de 2016 qui relevait que seulement 2,1 % des utilisateurs de Microsoft 365 déclaraient utiliser activement SharePoint (1,2 % concernant Yammer, sur lequel je vais revenir plus bas). Cette étude datait de 2016 mais les choses n'ont pas changé avec le déploiement de Teams : on va ainsi devoir expliquer l'usage des équipes à des utilisateurs qui n'utilisent que les fonctionnalités de Chat et de réunion en ligne (les anciennes fonctionnalités de Skype for business...) et n'utilisent pas les fonctionnalités collaboratives des équipes !

La raison essentielle qui explique cette situation me parait être la faiblesse du dispositif de gouvernance fonctionnelle, une fois que le projet de déploiement est terminé.

La première erreur vient de l'approche "Projet" du déploiement de Microsoft 365

Vous avez mis en place un projet SharePoint il y a 1 an déjà et vous souhaitez pendre des nouvelles de celui-ci chez votre client ?

Le dispositif alors en place est généralement beaucoup moins fourni que pendant le projet mais il se peut même que vous ne connaissiez plus les interlocuteurs encore "sur le pont".

Leur rôle est généralement le suivant :

• Un administrateur technique qui est en charge de la gouvernance opérationnelle de SharePoint, assurant la gestion des accès et des licences sur Online ou l'infra quand on est en environnement Server,

• Un développeur pour la gouvernance applicative lorsqu'il y a à gérer les éventuels compléments achetés ou développés maison,

• Une équipe Help Desk "Utilisateur" pour gérer les incidents que je rattacherais comme dispositif appartenant à la gouvernance fonctionnelle.

Si vous leur posez la question sur la qualité de l'adoption de la solution mise en place, quand vous aurez des réponses, vous n'obtiendrez généralement hélas pas une analyse partagée entre les 3 parties prenantes citées plus haut, basée sur des données sur la qualité de l'adoption : au mieux, vous obtiendrez le nombre d'incidents et leur taux de résolution, le nombre d'interventions de type TMA corrective, adaptative ou évolutive, le nombre de visites sur la page la plus visitée quand il s'agit d'un intranet (la fameuse page affichant le menu de la cantine...).

L'équipe Projet est partie sur d'autres projets : plus personne ne semble encore s'intéresser à la qualité de l'adoption, au fait que la solution proposée rencontre ou non son public, que l'organisation, au travers d'elle, atteigne ou non les objectifs fixés à son lancement. La solution serait de considérer que l'adoption de pareils outils (SharePoint en particulier et M365 en général) requiert la mise en place d'un dispositif continu qui doit survivre à la phase Projet.

La seconde erreur est de sous-estimer le dispositif d'adoption après le projet de déploiement

Lorsqu'il s'agit de déployer SharePoint ou Yammer en organisation, vous avez sans doute déjà entendu parler de la pertinence de mettre en place un rôle d' "ambassadeur" ou de "champion" (terminologie plus "US").

Concept adopté par Microsoft au moment de la sortie de Teams en 2018 dans sa documentation (c'est le terme utilisé dans la documentation officielle sur le site plus récent "Become a champion"), ce rôle a été repris de ce que faisaient des entreprises spécialisées dans la conduite du changement. Ces entreprises ont été confrontées à des défis importants lorsqu'il a fallu accompagner leurs clients dans le déploiement d'outils de type réseau social d'entreprise. Pour y répondre, elles ont ainsi proposé à leurs clients de les accompagner dans la mise en place de ce rôle de relais entre le Community Manager et les participants au réseau social interne à l'organisation.

Si votre organisation a connu l'échec lors du déploiement de son réseau social d'organisation (souvenez-vous, plus haut, quand je citais que seuls 1,2 % des utilisateurs déclaraient en 2016 utiliser activement Yammer) vous tenez là une des raisons majeures expliquant cet échec : ce n'est évidemment pas la seule raison mais j'y reviendrai plus bas lorsque je parlerai du "Why".

Ce rôle d'ambassadeur ou de champion s'inspire de celui de "correspondant bureautique", mis en place dans les organisations dans la décennie 1990-2000. En effet, au moment du déploiement à grande échelle de la micro-informatique, les organisations se sont aperçu qu'accompagner les utilisateurs dans l'adoption du Pack Office ne répondait pas à la même logique que de former des opérateurs sur un système informatique transactionnel, i.e. qui permet de créer, de corriger ou de supprimer un enregistrement dans une application métier. Avec le Pack Office, les organisations ont eu besoin de former les utilisateurs à des outils de création de fichiers et, pour gagner en pertinence avec les sujets propres à chacun, le correspondant bureautique était identifié au sein d'un service autant pour sa connaissance du fonctionnement de ce service que pour ses aptitudes à former ses collègues.

Ce rôle d'ambassadeur ou de champion s'inspire donc bien de celui de correspondant bureautique mais il est différent et requiert des qualités supplémentaires. La raison à cela est que les outils informatiques n'appartiennent pas à la même catégorie : le pack Office est une suite de productivité individuelle alors que SharePoint, Yammer et Teams sont des outils collaboratifs. Par conséquent, les qualités requises pour être un bon ambassadeur ou un champion sont différentes : pour parvenir à ancrer de nouveaux usages, permettre ainsi une nouvelle étape de digitalisation de processus dans les organisations, nous devons compter sur les relais, les correspondants bureautiques et les champions/ambassadeurs mais également intégrer dans le dispositif un troisième type de personnage clé qui va exploiter les outils de la Power Platform : le "Power User" ou "Citizen Developer".

Chaque rôle a une fonction différente, nécessitant des qualités différentes pour les endosser, variant suivant la typologie d'outil :

• Outil de productivité individuelle (comme Word, Excel, PowerPoint, Outlook avec ses différentes dimensions e-mail, calendrier, tâches et notes mais également To Do, OneNote, OneDrive et Forms en conception solo) qui requiert une fibre de pédagogue, de formateur et de coach individuel (pas besoin d'être interne à l'organisation) ; important par le passé, ce rôle de correspondant bureautique est sous-estimé actuellement dans le dispositif, alors qu'il reste d'actualité quand on prend en compte le flux de mises à jour Office Online qui se déverse en continu ;

• Outil de productivité de groupe (comme SharePoint, Yammer, Stream, Kaizala, MS Teams, Planner, et Forms en conception d'équipe) qui nécessite des qualités supplémentaires de "leader" convaincu et stimulant et faisant preuve d'empathie, avec des qualités de communication et d'animation ; en plus de ses qualités de formateur-démonstrateur, l'ambassadeur/champion doit porter le changement en étant exemplaire ; pour ne pas être déconnecté de la réalité quotidienne de l'organisation, je suis convaincu qu'il ne peut être qu'interne à l'organisation ;

• Outil de création d'application Métier (les outils de la Power Platform Power BI, Power Automate, Power Apps, Power Virtual Agents mais également les Lists 365 dans Ms Teams et donc dans SharePoint dans lequel on peut ajouter des listes, bibliothèques et des applications pour créer des applications Métiers) dont le casting nécessite de faire appel à un personne qui est pour le changement, qui plus est technologique, connait les données et les processus Métier concernés, être légitime aux yeux des collègues qu'elle représente et enfin, elle doit rester dans le cadre imposé par la gouvernance du dispositif ; pour toutes ces raisons, le Power User est interne à l'organisation.

Changer de scénario ne va pas se faire tout seul

J'emprunte maintenant une formule à l'excellent Christophe Coupez : "Adopter Microsoft 365, c'est changer de scénario".

Pour changer de scénario, je n'ai pas trouvé d'autres solutions que de répéter l'importance de la gouvernance, en y intégrant ces rôles dans un chapitre fonctionnel, pour piloter l'atteinte des objectifs d'adoption, en suivant des métriques en lien avec la qualité de l'expérience utilisateur ressentie, de manière à apporter des réponses aux difficultés...

Pour faire vivre le projet de transformation initial au-delà de la phase de gestion du projet, je parle donc de programme d'adoption : "Adopter M365, ce n'est pas un projet ; c'est un programme qui s'étendra sur plusieurs années". Ce "programme" sera donc un dispositif permanent qui survivra à la phase Projet, permettant de rencontrer le succès sur la durée et à l'échelle visée.

Enfin qui dit "Programme", dit "Direction de programme" : voilà pourquoi que je milite pour la mise en place d'un Monsieur-Madame Microsoft 365 dont la fonction sera de mettre en place le dispositif de gouvernance fonctionnel, définir les articulations entre ces rôles plus ou moins nouveaux : relais bureautiques, ambassadeurs/champions, Power Users.

Lorsque j'évoque la gouvernance du dispositif d'adoption de Microsoft, j'introduis la nécessité de mettre en place ce rôle de "M. Mme 365". Ce rôle sert à définir, coordonner et mesurer l'efficacité et ainsi ne pas se retrouver à n'utiliser que 10% des fonctionnalités alors que l'on paie 100% de la licence. M. Mme 365 va permettre d'installer de façon durable le "Why ?", i.e. les enjeux du programme à communiquer, et à ordonner les projets dans une feuille de route réaliste, au-delà de la nécessaire explication préalable : « quel outil pour quels usages ». Pour veiller à la bonne visibilité du cap suivi et du dispositif auprès des métiers, M. Mme 365 surveille la cohérence de l'ensemble, de la bonne gouvernance des données surtout sensibles.

Il va ainsi orchestrer les 4 rôles mentionnés ci-dessus, en fonction de ce cap, en mettant en place une stratégie avec des objectifs à déterminer en équilibre avec les contraintes. En effet, M. Mme 365 aura un rôle en lien avec la gouvernance opérationnelle (déploiement des licences avec une approche Conduite du changement) et avec la gouvernance applicative (relations concernant la fabrique des applications avec les développeurs).

Voilà donc quelques-unes de mes idées que je vous partage aujourd'hui par écrit mais je vous propose de nous retrouver prochainement à la conférence aMS Lausanne le 19 avril prochain (possible de la suivre en ligne) pour aller plus loin dans cette réflexion.

A très bientôt sur ce thème.