Kit de démarrage en collaboration avec SharePoint – Partie II

Tel que mentionné dans mon compte-rendu de ma participation à l’événement SharePoint Summit 2014 – Montréal, j’ai l’intention de publier une série de billets sur le Kit de démarrage en collaboration avec SharePoint. Le contenu de ces billets découle de ma session de trois (3) heures livrée dans le cadre du SharePoint Summit 2014. La structure sera la suivante :

  1. Introduction et mise en contexte
  2. Le Kit de Démarrage – Les éléments structurants
  3. Le mode Comités et Unités
  4. Le mode Communautés
  5. Le mode Projets
  6. Conclusion

Je vous présente ici la deuxième partie qui couvre les éléments structurants du Kit de démarrage.

Les éléments structurants

Avant même de penser à SharePoint, il faut se poser une série de questions importantes qui permettront de définir les assises de toute solution basée sur SharePoint. Cette activité se nomme Architecture d’Information.

Traditionnellement, cette activité se concentrait sur la façon dont un site web était structuré (navigation, éléments, découpage, etc.). Suite à mes expériences en gestion de l’information et à plusieurs mandats de réalisation de sites SharePoint, j’ai étendu le concept pour couvrir les volets essentiels de toute solution basée sur SharePoint.

Dans un contexte SharePoint, l’architecture d’information comprend les étapes suivantes tel qu’illustré dans cette figure:

Architecture d'Information - SharePoint

Les grandes étapes de l’architecture d’information sont:

  1. Atelier de découvertes – Une prise de connaissances de la situation actuelle et non pas de la solution envisagée. Durant cet atelier, on fait le tour du jardin; on obtient un portrait de la situation actuelle; on recense les problèmes et opportunités mais on évite les solutions. On doit ici résister à la tentation de montrer un site SharePoint car on perd alors le recul nécessaire pour exprimer des besoins et non pas des solutions.
  2. Les besoins – On formalise les besoins en fonction des découvertes faites durant l’atelier précédent. Les besoins doivent toujours être considérés en fonction du contenu et selon les axes suivantes – Quoi, Qui, Comment et Quand). On peut aussi prioriser les besoins selon divers facteurs tel que les impacts (processus / humains / financiers), les ressources requises, etc.
  3. Gouvernance – On établit formellement notre vision et notre approche de gouvernance en fonction de la portée de notre solution et de son éventuelle évolution. La clé ici est de ne pas essayer de gouverner SharePoint mais bien de gouverner ce que l’on en fait. La gouvernance ne doit pas être considérée comme un élément sur une liste de vérification mais bien une activité récurrente qui vivra aussi longtemps que vos solutions vivront. C’est aussi un équilibre entre les besoins de rigueur de niveau TI et les besoins de flexibilité requis par les utilisateurs. Une de façons de faire vivre la gouvernance est souvent de créer un groupe d’utilisateurs à l’intérieur de participation ou de participer activement à un groupe d’utilisateur comme le groupe d’utilisateurs SharePoint Québec
  4. Hiérarchie SharePoint – On établit la structure de la ferme en termes d’éléments technologiques (serveurs, applications Web, services applicatifs, collection de sites, etc.) pour appuyer la solution envisagée. Cette activité doit être réalisée conjointement avec les ressources TI. Plusieurs facteurs influencent les choix fait ici dont le besoin d’isolation à des fins de sécurité, la performance attendue, la volumétrie du contenu, etc.
  5. Structure des contenants SharePoint – C’est ici que l’on fait l’arrimage entre les besoins exprimés précédemment et les éléments SharePoint (liste, bibliothèque, site, etc.). Les contenants SharePoint sont en fait les outils de notre coffre qui nous permettent de bâtir nos solutions. On fera alors la promotion de la réutilisation et de la consistance de l’expérience utilisateur en favorisant la construction de gabarits (listes, bibliothèques, types de contenu, etc.) et de modèles de sites qui utiliseront ces gabarits. L’idée ici est d’en arriver à fournir des sites sur une base d’assemblage de composants plutôt que d’avoir à tout refaire à chaque fois.

Pour plus de détails sur cette activité essentielle qu’est l’architecture d’information, je vous invite à consulter cet article qui a été publié sur le blogue des MVP de Microsoft.

Dans le prochain article, nous discuterons des divers modes de collaboration couverts par ce kit de démarrage.