Ce billet ouvre une série de 5 billets sur le thème "5 évidences sur la gouvernance SharePoint". évidence 1 : sauteriez-vous d'un avion sans parachute ? évidence 2 : le gourou de la gouvernance n'existe pas évidence 3 : la gouvernance est un projet documentaire à part entière évidence 4 : la gouvernance constitue une sécurité pour garder le "client" au centre du jeu évidence 5 : en suivant la Road Map de Microsoft, vous n'y couperez pas Se lancer dans un projet SharePoint sans établir clairement les rôles et les tâches de chacun, cela revient à sauter d'un avion sans parachute et à prendre le risque de ne pas parvenir à "poser le projet en douceur". Cela s'explique par le fait que notre réflexion est historiquement basée sur la croyance que le développement informatique, seul, peut tout : nous pensons que les outils technologiques vont nous sauver. Or, SharePoint est un projet à fort impact organisationnel. Vous pouvez être d'accord avec la nécessité de vous organiser mais, le jour venu du lancement du projet, comme souvent, vous allez être happé par le quotidien et le plan de gouvernance ne verra jamais le jour ; on compte sur vous pour que le projet aboutisse à un succès et vous n'avez pas forcément le soutien de votre management pour structurer une démarche de gouvernance plus formelle que de coutume, surtout par rapport aux utilisateurs finaux que l'on implique pas plus que la définition des besoins et des tests d'acceptation. Généralement, la raison est que vous disposez d'un interlocuteur pour l'infrastructure informatique et que vous vous occupez de la supervision des développements en relation avec vos utilisateurs finaux. Vos "Best Practices" vous imposent généralement des règles en matière de "Business Continuity" et "Disaster Recovery", de sécurité et d'autorisation mais la gouvernance d'un projet SharePoint dépasse les aspects d'infrastructure et de sécurité. Si vous êtes soumis à des règles de documentation concernant la documentation du code développé sur-mesure, là aussi, le plan de gouvernance devra comporter une partie Développement mais qu'en sera-t-il du paramétrage sur-mesure de votre SharePoint ? Comme SharePoint est une plateforme personnalisable, elle requiert un effort de gouvernance plus fort pour l'équipe de conception de la solution. La gouvernance concerne également la dimension "fonctionnelle" ; les choix de paramétrage avancé et de développements spécifiques devront être pris en fonction du degré de maturité des utilisateurs et de la nature de l'information traitée : la personnalisation des vues de liste/bibliothèque, fonctionnalités avancées de version, d'extraction ou de coédition, d'approbation, de workflow de publication, l'utilisation des ensembles de documents, la mise en archive courante, intermédiaire ou définitive, la personnalisation du moteur de recherche, les fonctionnalités liées aux pratiques sociales et communautaires… Parmi les 3 types de gouvernance à intégrer à votre plan général, j'ai coutume de dire que la gouvernance fonctionnelle est le parent pauvre de la gouvernance au niveau outils et méthodes. C'est bien là une raison d'une AMOA forte autour du projet : SharePoint est un généralement un projet à impact organisationnel élevé et la conception de la solution doit être centrée sur la nécessaire adhésion des utilisateurs. Oui, des méthodes existent pour réaliser des analyses "métier" et maquetter des cas d'usages mais on ne parle là que de la conception et non de la gouvernance fonctionnelle tout au long de la vie du projet. Par exemple, savez-vous qu'il existe 33 types d'éléments SharePoint que vous devrez paramétrer pour chaque niveaux d'autorisations ? Il existe également des outils tiers pour automatiser certaines tâches non prévues initialement par Microsoft mais ces outils ne sont que des assistants pour réaliser les tâches dévolues à la bonne gouvernance fonctionnelle de votre solution. En fonction de votre SharePoint, il faudra déterminer la gouvernance fonctionnelle dont vous aurez besoin : éditoriale, communautaire, taxonomique…? Bâtir un plan de gouvernance pour votre projet SharePoint peut vous apparaître comme une énorme charge de travail supplémentaire ; s'ajoutant à votre quotidien qui est de mettre le projet sur les rails, de le livrer et… c'est tout car, ensuite vous devrez de toute façon passer à autre chose… Cela peut vous paraître d'autant disproportionné et superflu au regard du périmètre de votre projet : en soi, ce n'est pas une mauvaise chose car cela pourrait signifier qu'au moins, votre premier projet SharePoint est de taille modeste (ce qui est recommandé, j'ai entendu Xavier Vanneste parler de l'effet "nénuphar", "les nénuphars s'ouvrant les uns après les autres pour remplir progressivement la mare"). Or, c'est justement ce premier petit projet qui constituera l'occasion la plus facile à saisir pour établir votre premier plan de gouvernance et introduire des Best Practices liés à votre SharePoint. Si vous n'établissez pas de plan de gouvernance, il est possible que ce soit tout le contraire qui se produise et que vous ne puissiez jamais passer complètement à autre chose. Ne pas établir les règles de gouvernance est un excellent moyen pour se rendre indispensable et ne jamais pouvoir sortir du projet. Le plan de gouvernance représente donc à mes yeux le parachute qui va vous aider à atterrir en douceur, comprenez à livrer le projet de la façon la plus contrôlée aux différentes parties concernées : avoir repris la charte de vision qui comporte les enjeux, objectifs et impératifs du projet puis avoir établi qui (?) fait quoi (?) et pourquoi (?), quand (?) et comment (?) pour couvrir toute la vie de votre projet SharePoint, de la conception-réalisation à la phase de maintenance continue. La seconde évidence est "le gourou de la gouvernance SharePoint n'existe pas".

Pourquoi se soucier encore et toujours de l'adoption en informatique ? Il est toujours bon de rappeler que les projets informatiques doivent être abordés avec beaucoup d'humilité ; si on regardait les chiffres que certains cabinets d'études brandissent quand il s'agit de faire le bilan sur la réussite de projets ? The Standish Group's publiait en 2011 dans le « CHAOS Study » que 66 % des projets informatiques étaient en échec, soit total (abandon) soit partiel (dépassement des coûts ou des délais, périmètre incomplet). (le niveau de détail supplémentaire ?) ; parmi les facteurs clés de succès, en deuxième position après l'importance donnée au support du sponsor, vient la bonne gestion de l'adoption par les utilisateurs, avant même l'importance du choix d'un chef de projet expérimenté. Une autre étude publiée par Oracle en 2012 visait à démontrer que l'expérience d'utilisation est désormais un élément clé de la qualité ressentie et que presque 81 % des clients sont prêts à payer plus (5 %) pour avoir une meilleure expérience d'utilisation (Oracle, 10/12/2012). Payer 5 % de plus pour avoir la garantie que le projet soit adopté dans des meilleures conditions démontre que nous sommes loin des 20% que nous avons l'habitude de mettre en avant lorsque nous évoquons les coûts liés à la gestion de projet et l'assistance à maîtrise d'ouvrage. La faute n'en revient donc pas nécessairement aux professionnels du secteur mais à un contexte d'achat tendu par le contexte économique et par le fait qu'ils ont déjà connu des projets qui ont coûté trop cher puisqu'ils ont fini en échec : avoir conscience et répéter qu' « investir dans la maîtrise de l'adoption, c'est faire des économies », cela fait partie du « job ». Et cela est encore plus vrai pour un projet SharePoint ! Non pas que la maturité du produit soit en cause mais en raison de la nature "à finir soi-même" de SharePoint : SharePoint faisant partie intégrante de la suite Office, beaucoup ont tendance à penser que l'on doit se soucier de l'adoption de SharePoint comme on se soucie de l'adoption de Word, d'Excel ou de PowerPoint... SharePoint a vocation à organiser le travail bureautique, souvent dans des configurations d'organisation avec processus faiblement formalisé, où règnent depuis près de 20 ans, la messagerie internet et le serveur de fichiers partagés. Si vous avez le même SharePoint que votre voisin(e), c'est que vous n'avez pas suffisamment approfondi votre relation à votre SharePoint... SharePoint n'est pas une application métier mais est un produit, une plateforme qui va recevoir vos solutions personnalisées. Pour le métier de concepteur de solution SharePoint, j'utilise volontiers l'image d'un cuisinier : SharePoint met à dispositon du chef une batterie d'ingrédients, parmi lesquels les fonctionnalités de réseaux sociaux d'organisation, de moteur de recherche, de gestion électronique de documents, de formulaires, de workflows comme autant d'ingrédients. SharePoint ne fait donc pas encore de vous un cuisinier hors pair… Il reste qu'il vous faudra alors posséder le savoir-faire pour réaliser de bons petits plats, digestes pour vos utilisateurs finaux. C'est la raison pour laquelle, pour réussir son adoption réussie de SharePoint, je recommande de commencer son étude de projet SharePoint par une formation pour faire le tour des ingrédients mis à disposition. Ensuite, vous devrez accompagner le déploiement de votre solution auprès de vos utilisateurs (car l'informatique seule ne peut tout...) et l'intégrer à un plan de gouvernance sans lequel vous ne pourrez atteindre durablement vos objectifs.

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

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

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

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

Le second temps de la formation : planifier une formation à votre solution SharePoint réalisée sur-mesure Le premier temps de la formation a consisté à se former aux fonctionnalités de base de SharePoint venant se greffer à l'univers Office de vos collaborateurs ; en effet, déployer un SharePoint revient à introduire une nouvelle couche de fonctionnalités pour la gestion électronique de leurs documents : chercher un document, enregistrer et classifier l’information, gérer des versions, utiliser des workflows de validation et de publication… Le second temps de la problématique "Adoption de SharePoint et formation" ne consistera pas en une formation à SharePoint mais correspondra à la préparation et l'animation de session de formation à destination de vos collaborateurs, portant sur la solution Métier conçue au travers de SharePoint, une formation à ancrer dans le cadre de leur quotidien au travail. Je recommanderai presque de limiter dans la mesure du possible le terme SharePoint dans le vocabulaire de votre projet lorsque vous vous adressez à vos utilisateurs finaux car l’appropriation en sera d’autant plus facilitée, non pas qu’il faille cacher aux utilisateurs que SharePoint est l’outil utilisé mais parce que, dans la logique d’une solution à « finir soi-même » : pour caricaturer mon idée, si vous devez former vos utilisateurs finaux à « SharePoint », c’est que vous avez manqué l’étape de conception de cette solution sur-mesure. J’ai fait mes premières armes dans la documentation d’éditeur de logiciels pour lequel il était plus évident pour ses clients de concevoir un plan de formation spécifique de manière à permettre à ses utilisateurs d’acquérir les connaissances nécessaires pour travailler dans ce nouvel environnement informatique ; il était de même lorsque ces clients demandaient des développements personnalisés spécifiques. La raison est que, pour les produits Office, on a trop souvent tendance à ne pas prendre cette dimension car l’environnement Office est déjà connu des utilisateurs finaux, que SharePoint peut respecter la logique utilisateur de l’organisation documentaire en place et que « c’est du Web et les utilisateurs vont sur Internet toute la journée… »

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 !