5 évidences sur la gouvernance | évidence 3 : la gouvernance SharePoint est un projet documentaire à

Le plan de gouvernance est le mode d'emploi de « l'objet SharePoint conçu », pour rendre son client autonome et satisfait à long terme.

Le gourou de la gouvernance n'existant pas, le profil du consultant SharePoint en charge de la gouvernance doit posséder des facultés à gérer un projet documentaire à l'intérieur de votre projet SharePoint global.

Sa mission va être de structurer l'information de la solution SharePoint conçue, en reprenant les étapes de la mise en place du projet ; au niveau de la conception fonctionnelle, le plan de gouvernance doit décrire la méthodologie :

1 | Charte de vision, indiquant les enjeux (la définition du projet , les bénéfices attendus, les facteurs de réussite), les objectifs (groupes et autorisations, audience du site, cas d'usages principaux) et les impératifs du projet (les contraintes et les risques)

2 | Choix du/des type(s) de site (critères d'identification des fonctionnalités générales du produit par rapport aux fonctionnalités métiers attendus)

3 | Choix des éléments de site à insérer, toujours en fonction des fonctionnalités Métiers attendues (applications et composants webparts), que je réalise à partir de mon formulaire de capture des besoins, partie intégrante de ma version de matrice de déploiement et de gouvernance

4 | De ces choix fonctionnels, découlera l'architecture de l'information en terme de navigation et de métadonnées, les paramètres de déploiement en termes d'infrastructure et les choix de développements additionnels

N'oubliez pas que, dans une optique de création d'un centre de services, le travail de documentation va se standardiser puisque vous vous appuierez sur une "bibliothèque" de modèles de site et d'éléments de site.

Etablir le tableau des rôles et des responsabilités et écrire non pas 1 mais 3 modes d'emploi "sur-mesure"

Le consultant en gouvernance SharePoint a ensuite pour mission de répondre à la place de son client aux questions suivantes : qui (?) fait quoi (?) et pourquoi (?), quand (?) et comment (?) pour couvrir toute la vie du projet de la conception-réalisation à la phase de maintenance continue.

Le consultant en gouvernance est donc en charge d'établir le tableau des rôles et des responsabilités sur l'ensemble des 3 domaines de la gouvernance (exploitation opérationnelle Infra, développement et fonctionnel). Sujet parfois éminemment "politique"...

Ce partage des tâches ne s'effectue généralement qu'en connaissance de causes, c'est-à-dire sur la base des actions à réaliser ; le consultant en gouvernance va donc devoir préparer 3 "modes d'emploi" sur mesure, correspondant aux 3 domaines de la gouvernance, pour transmettre les informations et les meilleurs conseils adaptés à l'environnement de chaque client : il ne suffira pas de copier des listes d'URL vers le TechNet mais bien de fournir au public cible de chacun des "3 modes d'emploi" l'information répondant à un besoin donné.

Les 3 plans spécifiques ont pour point commun qu'ils contiennent :

• Les règles de conception, de pilotage ou d'utilisation et de suivi de la solution

• L’organisation et les moyens humains mis en œuvre pour maintenir et faire évoluer durabement la solution

Des nécessaires qualités de vulgarisation conduisent à choisir le consultant en AMOA, comme le consultant en gouvernance...

Le gourou de la gouvernance n'existant pas, le rôle du consultant en gouvernance va être de centraliser l'information que possède chacun des 3 responsables des domaines de la gouvernance pour la traiter de manière à livrer une documentation la plus "exploitable" possible : tous les formateurs connaissent la difficulté de se mettre au niveau de leurs stagiaires, c'est souvent le consultant en charge des aspects utilisation fonctionnelle qui est pressenti car le souci de parvenir à vulgariser un contenu technique est d'autant plus sensible lorsqu'il s'agit d'adoption par les utilisateurs finaux.

Même s'il est généralement en charge de l'interface avec les utilisateus finaux, le consultant AMOA SharePoint participe à la gestion du projet et ainsi possède des qualités de vulgarisateur technique qui font de lui un bon candidat au rôle de consultant en gouvernance.

Il sera à même d'assurer également l'interface de communication entre profils techniques puisqu'il va mettre l'information au plus haut de vulgarisation qu'il comprendra.

Ma mission de gouvernance va-t-elle me conduire à produire une documentation qui sera jugée volumineuse et inutile ?

Ce que l'on reproche traditionnellement à la documentation s'appliquera-t-il à ma mission de gouvernance ? C'est ce qui entraine souvent un risque d'échec dans la mise en place d'une gouvernance SharePoint : la documentation va être jugée comme étant volumineuse, pas assez pratique et sa nécessaire actualisation ne sera pas réalisée.

Or, ceux d'entre vous qui, comme moi, viennent du monde de l'édition logicielle, sont peut-être plus familiers de ce sujet et savent que le législateur européen a énoncé qu'un producteur doit accompagner ses produits d'une documentation (norme européenne CE). L'obligation d'établir la documentation technique comme base de la performance déclarée revient au fabricant mais, dans le cas d'un déploiement SharePoint, pour un intégrateur de solution "sur-mesure", comment voulez-vous qu'il en soit autrement, avec le bon sens qui régit vos affaires ?

Conseils pour convaincre son management : la gouvernance produit des résultats !

Si vous voulez mettre en place une gouvernance, il faut qu'elle soit reconnue et une belle déclaration ne suffira pas : le plan de gouvernance doit faire partie intégrante du schéma directeur stratégique de l'organisation ; à ce sujet, la matrice de déploiement peut aider à apporter une vue synthétique du présent et du futur

Pour que la gouvernance soit reconnue, il faut qu'elle produise des résultats et balayer l'idée que la gouvernance représente une charge supplémentaire pour au moins 2 raisons :

• la documentation de la gouvernance va être transformée pour être recycler en documents utiles pour la formation et la communication (ce que j'appelle la partie émergée de l'iceberg) ; par exemple, les cas d'usages peuvent être déclinés en mode opératoire pour une aide en ligne ; il est évident qu'il est infiniment plus utile d'obtenir une aide sous la forme d'une infobulle pertinente que de chercher le sens dans une documentation technique (même indexée par le moteur de recherche de SharePoint)

• enfin, la mission de gouvernance va permettre la mise en place des métriques de gouvernance que ce soit avec des outils tiers au niveau infrastructure (comme AvePoint, Axceler ou avec vos propres tableaux de bord réalisés avec Visio [bonjour à Patrick Guimonet, Nicolas Georgeault et Michel Laplane) ou au niveau fonctionnel (comme AvePoint, RSD, Newsgator, Webtrends...)

Une 3e raison pourrait être que l'exercice de la documentation est une bon révélateur de l'usabilité d'une solution ; Nicolas Boileau-Despréaux n'énonçait-il pas dans l'Art Poétique (1674) "Ce qui se conçoit bien s'énonce clairement - et les mots pour le dire arrivent aisément." (Merci à Pierre Adam pour m'avoir rappellé cette citation ;) ).

C'est un aspect que je développe dans l'avant-dernier billet de la série "5 évidences sur la gouvernance" : évidence n°4 | la gouvernance constitue un constitue une sécurité pour garder le "client" au centre du jeu.