"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.