À la lecture d'un cahier des charges d'un projet SharePoint, il a dû déjà vous arriver d'avoir la sensation étrange que le besoin fonctionnel a été décrit sans lien direct avec SharePoint bien qu'il soit mentionné que la solution technique choisie soit SharePoint. Pour ma part, j'imagine que les rédacteurs du cahier des charges ont dû se faire aider par une assistance à maitrise d'ouvrage qui ne connaissait pas SharePoint. J'expose dans ce billet les raisons pour lesquelles je pense qu'il est préférable de choisir une AMOA qui connaisse SharePoint. La raison la plus fréquemment rencontrée est que le cahier des charges est de nature à comporter davantage la vision du projet que l'analyse fonctionnelle détaillée ; on y retrouve alors les éléments d'analyse nécessaires mais non suffisants pour "lancer" le projet : les enjeux, les objectifs et les impératifs du projet. Quels sont les types d'AMOA qui ont été choisis pour établir ces éléments ; ils peuvent être de plusieurs natures, plutôt en fonction du type de projet SharePoint : Des conseils en communication plutôt orientée marketing, pour des projet de sites internet, intranet ou extranet Des conseils en communication plutôt orientée organisation, et stratégie, pour des projet d'intranet Une des raisons de ce choix s'explique parfois par le fait que les AMOA sont choisis de plus en plus souvent non par les directions informatiques mais par les directions de la communication/ressources humaines, qui sont en lien avec des agences de communication et de graphisme qui proposent leurs services en matière de conseils et stratégie Intranet. A mes yeux, il n'est pas primordial que le consultant en AMOA réalise obligatoirement cette partie du projet même si, dans un souci de meilleure gouvernance de projet possible, à mon sens, chaque la mission d'un consultant en AMOA démarre par le recueil du besoin et la conception de la solution. Par contre, le consultant en AMOA doit posséder la culture générale du fonctionnement des organisations suffisante pour intégrer ces aspects fondamentaux dans son projet car la gouvernance, le champ des fonctionnalités et le paramétrage vont, par exemple, être fonction du type de site : dans un souci d'efficacité, il est préférable de choisir une AMOA qui connaisse SharePoint pour bâtir la solution fonctionnelle en termes d'architecture et de fonctionnalités. Le consultant en AMOA qui connait SharePoint sera alors en situation : d'indiquer à son client lorsqu'il sort des usages prévus et s'engage sur la voie de développements spécifiques de proposer l'alternative de se recentrer sur l'utilisation standard du produit lorsqu'elle existe, quitte à limiter le champ de la fonctionnalité initialement prévue. Jeff Teper, Vice-Président SharePoint de Microsoft Corp., ne recommandait'il pas, à la sortie de SSP 2013, de commencer par utiliser SharePoint comme une application finie autant que possible avant de développer les couches de fonctionnalités personnalisée ? Les développements informatiques complémentaires sont ainsi minimisés et l'expérience utilisateur en sera également simplifiée : ceci peut être temporaire car une adaptation de SharePoint peut être nécessaires pour simplifier ou étendre fonctionnellement son SharePoint. C'est également sur la base de cette recommandation qu'ont été écrit les billets suivants : - "comment s'élabore la stratégie de formation à SharePoint", (la formation, une "Valse à 2 temps") ? - "Je vous présente ma matrice de déploiement et d'adoption SharePoint", constituée d'un formulaire de capture de besoins, de synthèses visuelles et d'une partie plan d'adoption.

Oh la belle idée que voilà : créer un centre de services SharePoint ! Idée à la mode que d'offrir des services "à la carte" à vos utilisateurs Je ne vous le cache pas : je suis également très friand de cette idée car elle est synonyme d'adoption, d'assistance à maitrise d'ouvrage, de formation et gouvernance simplifiée. Certainement que dès l'idée vous a été présentée, elle vous a intrigué, voir rapidement intéressé pour la voir mise en place : créer un centre de services informatiques à la demande consiste à appliquer le principe "Logiciel à la demande" (Software As A Service) en interne, comme règle de traitement des demandes utilisateurs, dans la continuité de la logique d'achat de services informatiques des organisations ces dernières années. Il s'agira de mettre un catalogue de services à disposition des Métiers. Les bénéfices pour les responsables de l'informatique sont connus : simplifier le travail et rationaliser les coûts en "standardisant" l'activité de conception et de déploiement informatique mais pas uniquement. Il se trouve que la version 2013 de SharePoint a été conçue pour une plus grande modularité et se prête logiquement à cette nouvelle vision du service informatique, au travers de sa logique d'architecture. Mais cette nouveauté ne concerne pas uniquement les changements-clés pour les services applications que l'on peut désormais déployer "partout": cette nouveauté porte en elle une approche qui simplifie la gouvernance car les rôles, responsabilités, la gestion des droits d'accès et de la confidentialité vont s'en trouver simplifiés : un centre de services SharePoint aide à rationaliser l'exploitation de l'infrastructure ; un contrat de niveau de service (Service Level Agreement) peut alors être associé au "service SharePoint consommé" par les Métiers concernés. les avantages de cette démarche "industrialisante" se retrouvent ensuite dans la gestion du cycle de vie des applications : elle permet de mettre en place une gouvernance orientée "Services" au sens ITIL, avec une facilité accrue d'adoption par les équipes techniques et Métiers concernées : l'accompagnement au changement s'appuie ainsi sur une standardisation de la documentation et de la formation. SharePoint 2013 se prête également plus facilement à cette philosophie en termes de fonctionnalités : la console d'administration de site contient désormais une fonctionnalité permettant de sauvegarder un modèle de site avec son contenu et ses paramètres. Avec l'approche de création de modèles, on standardise les paramètres d'architecture de l'information, évidemment, charte graphique et navigation mais également des paramétrages plus subtiles comme, par exemple, la personnalisation des vues de liste ou de bibliothèque. On se simplifie également la gestion des métadonnées pour l'optimisation de la pertinence du moteur de recherche ; j'en profite d'ailleurs pour vous signaler le prochain billet sur la gouvernance spécifique au moteur de recherche. Cette standardisation est opportune dès lors que vous êtes capable d'identifier les 20% de services qui recoupent les 80% des besoins clients (si la loi de Pareto était d'application dans votre cas) : vous possédez alors la structure de services SharePoint qui figurera dans votre catalogue de services. Vous serez alors en mesure de réinvestir du temps dans les projets de développement plus spécifique, par exemple, des APPS, les applications métiers "sur-mesure" basées sur SharePoint et Office, puisque Microsoft pense que vous n'y couperez pas (billet sur la gouvernance numéro 5 à venir).

Qu'entend-on par "formation à SharePoint" ? Adopter un SharePoint au niveau formation revient à prévoir une "valse à 2 temps". Premier temps, une formation "catalogue" à destination des concepteurs de la solution Comme dans toute relation, avant de s'investir dans des projets, n’est-il pas important de bien connaitre son partenaire, en l'occurrence SharePoint ? Etant donné que SharePoint est à considérer comme un "produit à finir" au niveau fonctionnel et que vous devrez concevoir une solution "sur-mesure", il faudra, dans un premier temps, prévoir une formation « catalogue » à destination des concepteurs fonctionnels de la solution. Je recommande donc de former tous les acteurs impliqués dans la conception de la solution SharePoint (administrateurs de collection de sites et de site, administrateurs applicatifs, Chef de projet et correspondants Métier) jusqu’à vos développeurs. Dépenser de l’argent dans une formation sur SharePoint peut vous permettre de faire des économies Vous pensez que vous n’avez pas le temps ou la formation va vous coûter cher que ce qu’elle va vous rapporter ? Et bien, je pense le contraire : se former à SharePoint avant de concevoir sa solution peut revenir à faire des économies, en évitant de réinventer la roue par la méconnaissance des fonctionnalités de base de votre SharePoint. Cette formation initiale doit vous servir à faire l'inventaire des nombreuses fonctionnalités et capacités de SharePoint et ainsi stimuler la créativité nécessaire à la conception de votre solution… Savoir de quelle manière SharePoint fonctionne vous évitera d'emprunter de mauvaises voies, de partir sur une mauvaise base en « détournant » une fonctionnalité de son mode de fonctionnement initial. En bref, éviter de faire compliqué quand on peut faire simple… ce qui n'est pas forcément évident, dès lors que vous avez en face de vous un formateur, théorique, non rompu aux expériences de déploiement de projet. Intervenant dans ce type de formation, je connais les limites de la formule et j’observe souvent le chemin qui reste à mes stagiaires pour atteindre leurs objectifs avec SharePoint : 5 jours pour faire un premier tour permet de se faire une idée du type de solution à apporter à vos utilisateurs (portail de publication, gestion électronique de document, moteur de recherche, etc.). Comme édicte le principe de Pareto, on va partir à la découverte des 20% de fonctionnalités qui permettent de traiter 80% des cas rencontrés. Il arrive ensuite que vous ressentiez le besoin d'approfondir certains sujets ; c’est à ce moment-là que votre partenaire en formation doit vous proposer un contenu de formation « sur-mesure », un accompagnement sur les fonctionnalités avancées de SharePoint qui vous intéressent, si vous avez besoin de développer un sujet fonctionnel bien spécifique de SharePoint: l'outil de publication des tableaux de Business Intelligence, l'outil de support à la gestion de projet, comment mettre en place un plan de gouvernance efficace, "le fabuleux Destin du moteur de recherche" de SharePoint, par exemple. Je vous invite à prendre connaissance du second temps de la valse !

Où en êtes-vous fonctionnellement avec votre SharePoint ? Comment produire une vue générale de l'existant et établir une feuille de route ? Ce billet présente une nouvelle version de la Capability Maturity Model pour SharePoint (CMMSP). Dans mon activité de conseil, j'ai utilisé jusqu'à la fin 2012 la Capability Maturity Model pour SharePoint (CMMSP). On peut remercier Guillaume Meyer qui, en 2011, avait fait connaitre, dans le monde francophone, l'existence de cette matrice, conçue et améliorée par Sadalit Van Buren de l'autre côté de l'Atlantique. Cette matrice pour SharePoint, est inspirée du Capability Maturity Model Integration (CMMI), modèle de référence regroupant des bonnes pratiques, destiné à mesurer la qualité des services rendus par les fournisseurs de logiciels informatiques du département de la Défense américaine. CMMI, utilisé en mode continu, est même un des modèles de processus accepté par la norme ISO 15504. Pour rappel, cette matrice permet d'offrir une vue synthétique de ce qui a été déployé en regroupant les famille de fonctionnalités : Fonctionnalités classiques : Publication, Collaboration, Processus Métiers et Recherche Fonctionnalités avancées : Réseaux sociaux d'organisation, Applications "composites", Intégration, Business intelligence Fonctionnalités de support : Infrastructure, Formation, Personnalisation En fonction des réponses aux questions, nous sommes en mesure de placer le curseur sur une échelle de 0 à 500 pour chaque famille de fonctionnalités, toujours par rapport aux capacités intrinsèques du produit SharePoint. Cette mesure quantifiée du déploiement de fonctionnalités par rapport aux capacités du produit permet ensuite une représentation synthétique visuelle. Par le biais de la pratique, le besoin d'affiner cette matrice s'est fait ressentir. Cette nouvelle version était indispensable à mes yeux, non seulement parce que la version 2013 de SharePoint nécessitait une mise à jour (la matrice des fonctionnalités "utilisateur" d'une manière générale, les parties Recherche, Collaboration, Réseau Sociaux et Communauté en particulier…) mais également parce que la matrice que j'utilisais pouvait gagner en pertinence par davantage de finesse dans l'énoncé des critères. Cette matrice est constituée d'un formulaire de capture de besoins, de synthèses visuelles et du plan d'adoption, le tout interconnecté aux modules de formations. Les incidences organisationnelles (l'ensemble des moyens à déployer) sont aussi prises en compte et constituent une voie d'amélioration intéressante car il est important d'identifier, le plus tôt possible, ces incidences dans la conception de la solution, en rapport avec la problématique de la gouvernance de votre projet SharePoint. Le temps nécessaire pour compléter les 200 questions du formulaire dépend de la maturité des interlocuteurs, i.e. de leurs connaissances SharePoint ; si certaines questions méritent un complément d'information (si vous ne connaissez pas les différents modes de gestion de version, je vais devoir vous les expliquer…), davantage de temps sera nécessaire. Au fur et à mesure que nous complétons ensemble le formulaire, le plan d'accompagnement (information, formation et documentation) est automatiquement quantifié. Cette matrice, pragmatique et relativement simple, offre aux décideurs une vue fonctionnelle synthétique à différents moments de la vie du projet SharePoint : la matrice permet de dépasser une vision de l'existant pour permettre de faire des projections stratégiques sur les prochains objectifs fonctionnels à atteindre en termes d'efficacité : elle est donc fort utile au moment de l'écriture du cahier des charges d'une nouvelle version… A partir de quel document communiquer avec les différentes parties au projet ? La matrice ! Que de temps gagné par la suite pour communiquer avec vos interlocuteurs Métier ou votre Direction stratégique, la matrice pouvant constituer un outil de communication tout au long de la vie du projet : Pour recueillir le besoin d'un nouveau projet, au moment de la capture initiale des besoins Pour réaliser un diagnostic et établir un plan de formation général Pour réaliser une mission d'audit, ayant pour objectif de savoir où vous en êtes et où vous souhaitez aller demain au niveau fonctionnel et organisationnel Pour synthétiser une mission de gouvernance, apportant une vision synthétique en complément de livrables documentaires parfois volumineux Pour établir une feuille de route pour un pilotage stratégique de vos solutions SharePoint avec un phasage en plusieurs versions N’hésitez pas à me contacter pour savoir où vous en êtres avec votre SharePoint ; je mettrai en application cet outil que j'ai rebaptisé "matrice de déploiement et d'adoption SharePoint" .

Certains de mes clients ne sachant pas par quel type d'application d'entreprise commencer par déployer sur leur intranet, je leur réponds généralement que le premier et le plus simple projet à mettre en place est le projet du moteur de recherche d’entreprise En effet, étant obsédé par l'inscription de votre SharePoint dans la vie réelle de votre organisation, le moteur de recherche d'entreprise peut permettre de créer rapidement de la valeur pour nombre de leurs collaborateurs généralement confrontés au problème essentiel de retrouver de l’information. Les bénéfices d'un moteur de recherche d'entreprise : - donnent immédiatement un sens positif au changement et consolide son ancrage dans la « vie réelle » au travail de l’utilisateur - de créer l’impulsion, de faire adhérer et de faire agir les utilisateurs, peu importe la maturité de chacun vis-à-vis de la technologie ; il améliore l’expérience utilisateur et évite de créer une nouvelle "fracture numérique" SharePoint a pour particularité qu’il est préférable de choisir une assistance à maîtrise d’ouvrage (AMOA) qui connaisse parfaitement SharePoint, de manière à bâtir des solutions sur-mesure fondées d’abord sur les fonctionnalités du produit : les développements informatiques complémentaires sont ainsi minimisés, l'expérience utilisateur simplifiée. La mission d’assistance à maîtrise d’ouvrage pour un projet moteur de recherche n’échappe pas à cette règle bien, au contraire ; les fonctionnalités liées au moteur de recherche mentionnées au cahier des charges sont généralement "permettre de retrouver de façon rapide et pertinente l'information" : peu de fonctionnalités exprimées au travers de cas d’utilisation en dehors de " la personnalisation du formulaire de recherche avancée et des filtres de recherche…" Or, obtenir la pertinence requiert de partir à la rencontre de tout un univers de besoins latents basés sur les usages propres à chaque organisation. La conséquence est que le projet du déploiement d'un moteur de recherche nécessite une analyse détaillée comme un projet documentaire à part entière, qui viserait à se représenter la "carte mentale et sémantique de l'organisation" de manière à déployer le moteur de recherche pertinent que les utilisateurs attendent ; il est donc recommandé qu’une AMOA puisse couvrir l’entièreté du cycle de vie d’un projet de moteur de recherche d’entreprise : Étape 1. Recueil du besoin Utilisateur (parfois rédaction de cahier de charges fonctionnelles en connaissance de cause permettant d’économiser une phase d’analyse détaillée complémentaire que le prestataire retenu souvent exige au démarrage de projet) - Recueil et analyse du besoin au niveau de l'architecture de l'information et le traitement des données associé (étudier les cycles de vie de l'information et les processus liés, identifier l'information ciblées par Métier et par type d'utilisateur, classer l'information en utilisant les techniques de carte heuristique ou la méthode du « card sorting » et en travaillant sur la proximité ; donner des libellés aux groupes d'information et observer la hiérarchisation pour une taxonomie multi-facettes ; sélectionner les colonnes à exclure de la recherche et/ou ajout de métadonnées ou de poids de métadonnées (dictionnaires acronymes, synonymes, non propagation, auto-complétion…) - Recueil et analyse du besoin au niveau de la personnalisation des interfaces (recherche simple, recherche avancée, fenêtres de résultats de recherche avec étendue(s) de recherche, filtres, bandeau de propriétés, déploiement de WebParts de recherche) Étape 2. Elaboration technico-fonctionnelle et mise en place organisationnelle de la solution - accompagnement de l’équipe de développement dans la phase de conception jusqu’à l’exploitation - accompagnement et conduite du changement auprès de tous les types d'acteur Clients impliqués dans le projet (conception-rédaction d'un plan de communication et de formation ; conception-rédaction d'un plan de gouvernance listant les rôles et les documentations de référence associées, pour aider les différents acteurs à intégrer durablement les principes de la bonne gouvernance de leur moteur de recherche) Étape 3. Tests (conception-rédaction et exécution de plans de tests ; des plans de tests à part entière, destinés à mesurer la valeur perçue par les collaborateurs) Étape 4. Communication et formation Étape 5. Évaluation et maintenance technico-fonctionnelle de la solution dès qu’une adaptation est nécessaire car le moteur de recherche est une "machine apprenante" reposant sur une taxonomie d'entreprise évolutive, à considérer comme une langue qui évoluera avec le temps. La mise en place de votre moteur de recherche d’entreprise est un projet à part entière, reposant sur la même logique de séquence d’analyse et de déploiement que n'importe quel projet de déploiement informatique mais basée sur des méthodologies davantage orientées "utilisateur" et projet "documentaire" : Scrum, méthodologie itérative (Agile), cas d’usage , techniques de carte heuristique (Mind Map) ou la méthode du « card sorting »...