SharePoint Summit 2014 de Montréal – Session « Demandez aux experts »

En plus de livrer une formation sur l’utilisation d’un Kit de démarrage en mode Intranet, j’animerai aussi une session de type « Demandez aux experts » durant l’événement SharePoint Summit 2014 de Montréal.  Cette session permet aux participants de poser des questions sur une thématique particulière. Ma session couvrira les aspects de planification d’un projet SharePoint, de gouvernance et d’architecture d’information. Les détails de cette session se trouvent ici  et les détails sur ma formation se trouvent iciOn vous attend.

SpeakerFRLogo

 

Advertisements

Architecture d’information dans un contexte SharePoint – Partie IV

Voici le quatrième article d’une série concernant l’architecture d’information dans un contexte SharePoint. Ces articles exposeront l’approche que j’utilise dans les projets SharePoint auxquels je participe. Cette approche est le fruit de mon expérience personnelle, de partage avec des ressources impliquées dans le domaine et de référence à certaines ressources reconnues dans en architecture d’information avec SharePoint comme Ruven Gotz, Richard Harbridge et Bob Mixon.

La Gouvernance

L’un des sujets les plus discutés et probablement des plus discutables concerne la gouvernance. La popularité de SharePoint ainsi que ses particularités ont fait ressortir un plus grand besoin de gouvernance mais aussi le besoin d’un nouvel équilibre entre les utilisateurs finaux et les équipes TI. Dès octobre 2008, je discutais déjà de gouvernance dans un contexte SharePoint et cette présentation a été offerte dans plusieurs forums tel le Groupe d’Usagers SharePoint Québec, le forum des architectes de Microsoft et la conférence SharePoint Summit.

Débutons d’abord avec une définition de la gouvernance dans le contexte d’un système d’information:

Ensemble de rôles, responsabilités et processus qui sont mis en place pour gérer le développement et l’utilisation d’une technologie

Dans la réalité, notre perception de la gouvernance est souvent différente: Nous avons plutôt l’impression que la gouvernance n’est en fait qu’un comité de professionnels qui définissent des politiques et des standards ayant pour but de limiter la flexibilité et l’utilisation des environnements technologiques. Dans un contexte de SharePoint où l’utilisateur final a et doit jouer un rôle majeur, il faut que notre perception de la gouvernance devienne la suivante:

Identifier et encourager les comportements agiles et adaptatifs dans un esprit de collaboration et non pas de confrontation

Pour qu’une approche de gouvernance ait une valeur et un sens, il faut être capable de mesurer les effets d’un énoncé de gouvernance. Plutôt que de dire – Nous encourageons la collaboration – nous pourrions plutôt énoncer – Nous allons prouver que l’organisation va croître tout en diminuant le volume de courriels et en centralisant les documents.

Au fil de mes expériences et de mes discussions avec des collègues, ma vision de la gouvernance s’est élargie pour maintenant couvrir plusieurs volets:

  • Volet Stratégie – Ce volet concerne la direction et la vision de l’offre de services SharePoint. On y jette les bases des diverses offres de services, on détermine les structures requises et la matrice de type RACI et on supporte le déploiement initial
  • Volet Architecture de l’Information – Ce volet concerne la façon dont la plateforme SharePoint sera utilisée pour supporter les besoins et répondre aux problèmes auxquels sont confrontés les utilisateurs.
  • Volet Services Informatiques – Ce volet concerne l’implication des équipes informatiques autant au niveau technique qu’au niveau des solutions
  • Volet Formation – Ce volet concerna la façon dont la formation sur les diverses offres de services et sur la technologie SharePoint sera livrée et dispensée dans l’organisation
  • Volet Image de marque – Ce volet concerne l’aspect visuel et la navigation à très haut niveau des divers sites
  • Volet Personnalisation et développement – Ce volet concerne les normes et standards de personnalisation et de développement de solutions dans l’environnement SharePoint

Ces volets peuvent être sous la responsabilité d’équipes multidisciplinaires:

  • Stratégie Affaires
  • Stratégie TI (Solutions et Technique)
  • Tactique – Développement
  • Tactique – Opérations
  • Tactique – Support

La particularité de cette vision de la gouvernance est qu’il faut être conscient que la gouvernance n’est pas un item à cocher sur une liste des choses à faire mais bien un mode de fonctionnement continuel et permanent. SharePoint offre plusieurs fonctionnalités permettant de supporter votre approche de gouvernance comme les modèles de sites qui permettent d’offrir une uniformité, des flux de travail d’approbation, des quotas, des facilités de suppression automatique de sites, etc. mais il faut d’abord et avant tout définir ce que l’organisation veut et ne veut pas faire.

Dans une organisation typique, on retrouve habituellement deux grandes zones de gouvernance:

  • Zone de haute gouvernance – Sites départementaux et portails organisationnels
  • Zone de basse gouvernance – Le volet MonSite, les espaces de travail et de projets, les sites de communauté et de centre d’intérêts

La zone de haute gouvernance laisse moins de latitude et de flexibilité et c’est là que la mise en place de gabarits (sites, listes, bibliothèques, types de contenu, etc.) vient compenser ce qui pourrait être perçu comme un manque de flexibilité. La zone de basse gouvernance est moins contrôlée et les artefacts qui y résident ne sont pas nécessairement des artefacts corporatifs devant faire l’objet d’une gestion  serrée.

Prêchez par l’exemple

Afin de démontrer que vous pratiquez ce que vous prêchez, il est de bonne augure de bâtir un site de type Centre de gouvernance où on retrouve les éléments suivants:

  • Liste d’Annonces pour les événements de gouvernance
  • Liste des solutions d’affaires avec les liens vers les sites contenant ces solutions
  • Liste des membres des diverses équipes de gouvernance
  • Les politiques et standards ainsi que le lexique
  • Les patrons et bonnes pratiques, les bons coups, les leçons apprises
  • Des sondages permettant d’obtenir de la rétroaction
  • La documentation formelle des divers comités de gouvernance

Conclusion

Cet article nous a présenté les éléments du bloc 3 – La Gouvernance. Dans le prochain article, nous couvrirons les éléments du bloc 4 – Hiérarchie SharePoint et du bloc 5 – Contenants SharePoint.

Le premier article de la série est disponible ici; le deuxième article de la série est disponible ici; le troisième article de la série est disponible ici.

Architecture d’information dans un contexte SharePoint – Partie III

Voici le troisième article d’une série concernant l’architecture d’information dans un contexte SharePoint. Ces articles exposeront l’approche que j’utilise dans les projets SharePoint auxquels je participe. Cette approche est le fruit de mon expérience personnelle, de partage avec des ressources impliquées dans le domaine et de référence à certaines ressources reconnues dans en architecture d’information avec SharePoint comme Ruven Gotz, Richard Harbridge et Bob Mixon.

L’Atelier de découvertes

L’idée de tenir un atelier de découvertes a été amené par Ruven Gotz et elle consiste principalement à discuter avec les utilisateurs potentiels des problématiques auxquels ils font face. En mettant l’emphase sur l’exposition des problèmes, par opposition à un besoin de solution, nous augmentons grandement les chances de livrer éventuellement une solution répondant à des besoins réels et non pas une solution à la recherche de problèmes. On comprendra alors qu’un des points majeurs de l’atelier est de ne pas montrer SharePoint durant l’atelier mais seulement à la fin de l’atelier.

Les points majeurs couverts le seront en fonction de la zone fonctionnelle où se situe nos problèmes. Ces zones peuvent être les mêmes que celles proposées par SharePoint comme par exemple:

  • Recherche
    • Quelles sont les difficultés actuelles liées à la recherche d’information?
    • Combien de temps prenez-vous pour un recherche un document?
    • À quel moment abandonnez-vous?
  • Gestion du contenu d’entreprise, y compris la gestion de contenu Web et la gestion documentaire
    • Exprimer les problématiques en fonction du cycle de vie (ex. création/réception, organisation, diffusion, disposition, etc.)
  • Portail et sites
    • Problèmes de prolifération non-contrôlée de site, problèmes de navigation, etc.
  • Collaboration et réseau social d’entreprise
    • Quels sont les freins au partage du savoir?

En plus des problématiques par domaine, on en profite aussi pour collecter de l’information complémentaire comme les contraintes organisationnelles, les règles de conformité, la politique de gestion des enregistrements, etc.

Atelier de découvertes

Atelier de découvertes

En fonction des audiences visées et de la grosseur de l’organisation, il est fort possible que vous devrez tenir plusieurs ateliers. Il s’agira alors de consolider les éléments recueillis. Durant ces ateliers, il faut penser en termes de problématiques réelles et non pas en termes de fonctionnalités désirées afin d’éviter que le mode solution ne prenne le dessus et cache les problématiques.

Lorsque les problématiques sont bien identifiées et exprimées, il sera plus facile de réaliser la prochaine étape – La cueillette des besoins

Les Besoins

En se basant sur les problématiques exprimées durant les ateliers de découverte, nous pouvons énumérer et catégoriser la liste de besoins. Ces derniers sont exprimés en fonction des grandes questions qui sont: Qui, Quoi, Comment, Quand et qui sont en fait, indirectement dérivées du cycle de vie d’un élément d’information.

Les Besoins

Les Besoins

Au niveau de la portée, on s’intéresse surtout à la volumétrie, à l’usage et aux diverses audiences ciblées par la solution. Au niveau de l’information visée, on s’intéresse au contenu devant être publié et au véhicule utilisé pour livrer/diffuser ce contenu. La confidentialité nous permettra de déterminer comment sera sécurité le contenu. La disposition s’intéresse au calendrier de rétention et au respect des lois et règlements régissant notre organisation et la façon dont elle traite son information. Finalement, la présentation s’intéresse à la façon dont l’information sera repérable et présentée aux utilisateurs.

Pour chaque type de besoin, on peut catégoriser ces derniers selon diverses perspectives:

  • Priorité – 1-Peu Important, 3-Souhaitable, 5-Essentiel
  • Efforts requis – 1-20-30 heures, 2-31-50 heures, 3-50 heures et +
  • Impacts – 1-10% productivité, 2-20%-50% productivité, 3-+50% productivité
  • Réutilisation – 1-Non, 2-Département, 3-Organisation
  • Support – 1-2 hrs/semaine, 2-5 hrs/semaine, 3-10 hrs/semaine
  • Formation – 1-autodidacte, 2-1hrs/utilisateur, 3-3 hrs/utilisateurs

Ces perspectives et ces échelles de valeur nous permettront par la suite d’évaluer et de prioriser le déploiement des solutions aux divers besoins et d’identifier rapidement les « Quick Wins », c’est-à-dire ces éléments qui ne nécessitent pas beaucoup d’efforts requis mais qui amènent des effets directs et intéressants sur la productivité.

Au niveau du volet de la gestion du contenu d’entreprise, il est impératif de réaliser une analyse exhaustive de ce contenu pour en retirer les éléments suivants pour chaque type de contenu:

  • Audience visées par le contenu
  • Les Propriétaires (auteurs), Approbateurs et Utilisateurs finaux
  • Les formats actuels des éléments d’information (tableaux dans Word, chiffriers Excel, document Word, document PDF, page numérisée, etc.)
  • Formats de publication – Format final de publication (Page Web, document PDF, etc.)
  • Localisations actuelles

Ce recensement permettra de déterminer l’ensemble des facilités requises pour faciliter la gestion des diverses étapes du cycle de vie de ce contenu. Plus cette étape sera précise et exhaustive, plus il sera facile par la suite de faire les bons choix de conception de solution.

Conclusion

Cet article nous a présenté les éléments du le bloc 1 – Atelier de découvertes et du bloc 2 – Les besoins. Dans le prochain article, nous couvrirons le bloc 3 – La Gouvernance.

Le premier article de la série est disponible ici. Le deuxième article de la série est disponible ici.

Architecture d’information dans un contexte SharePoint – Partie II

Voici le deuxième article d’une série concernant l’architecture d’information dans un contexte SharePoint. Ces articles exposeront l’approche que j’utilise dans les projets SharePoint auxquels je participe. Cette approche est le fruit de mon expérience personnelle, de partage avec des ressources impliquées dans le domaine et de référence à certaines ressources reconnues dans en architecture d’information avec SharePoint comme Ruven Gotz, Richard Harbridge et Bob Mixon. Dans ce deuxième article, nous couvrirons les cartes heuristiques et nous présenterons la vue d’ensemble de l’approche d’architecture d’information dans un contexte SharePoint avec les cartes heuristiques.

Origine et définition

La carte heuristique est un concept qui a été pensé par Aristote et formalisé par un psychologue anglais du nom de Tony Buzan. Le terme heuristique vient du grec ancien eurisko qui signifie Je Trouve.

Deux grandes définitions d’une carte heuristique:

  1. Un schéma qui est calqué sur le fonctionnement cérébral et qui permet de représenter et de suivre visuellement le cheminement de la pensée
  2. Outil permettant de mettre en lumière les liens qui existent entre un concept ou une idée et les informations qui leurs sont associées

Dans une architecture d’information, c’est la deuxième définition qui s’applique à l’utilisation des cartes heuristiques. La mise en œuvre d’une carte heuristique est simple. Au centre, on retrouve le thème ou le sujet principal en images et en mots. Des branches représentent par la suite des idées principales autour du thème central. On peut réaliser une carte heuristique manuellement ou à l’aide d’un logiciel.

Les domaines d’application des cartes heuristiques sont nombreux: La prise de notes, la préparation d’un exposé, le brainstorming, la structuration et la clarification d’idées, l’identification de mots-clés et, bien entendu, l’architecture d’information dans un contexte SharePoint. Il existe plusieurs outils de conception de cartes heuristiques:

  • Logiciels libres – xMind, FreeMind, Freeplance
  • Logiciels commerciaux – MindManager, SimpleMind, Inspiration
  • Logiciel en ligne – Exobrain, Mindomo, Mindmeister

xMind est celui que j’utilise personnellement.

Vue d’ensemble de l’architecture d’information

Cette carte heuristique présente la vue d’ensemble de mon approche d’architecture d’information dans un contexte SharePoint.

Architecture d'information dans un contexte SharePoint

Architecture d’information dans un contexte SharePoint

L’architecture d’information est composée de cinq (5) grands blocs d’activités qui, une fois complétés. nous permettrons de réaliser l’implantation de SharePoint pour supporter nos besoins initiaux. Il est important de comprendre que l’architecte d’information est le maître d’œuvre de l’ensemble des cartes heuristiques à produire mais que ce n’est pas nécessairement lui qui doit compléter ces cartes. Par exemple, le bloc 4 – Hiérarchie SharePoint peut être compléter par un architecte technologique ayant des connaissances SharePoint.

Les blocs majeurs sont:

  1. Atelier de découvertes – Ce bloc d’activités nous permet de faire un état des lieux afin de recenser et de connaître les problèmes réels. Il est primordial que ces problèmes ne soient pas exprimés sous forme de solution.
  2. Les besoins – Une fois les problèmes clairement identifiés, on peut maintenant effectuer la cueillette des besoins. On précisera alors la portée de l’initiative ainsi que les sujets importants comme la confidentialité de l’information, la disposition et la présentation.
  3. La gouvernance – Pour assurer que l’implantation et l’utilisation de SharePoint soit optimale dans notre organisation, il est important d’établir et de faire vivre un cadre de gouvernance qui comprendra plusieurs volets
  4. La hiérarchie SharePoint – C’est dans ce bloc d’activité que nous définissons les éléments de la technologie SharePoint qui supporteront nos besoins au niveau de la hiérarchie SharePoint (collection de sites, sites, zones, serveurs, etc.)
  5. La structure des contenants SharePoint – C’est dans ce bloc que nous faisons l’arrimage entre les besoins exprimés et les artéfacts offerts par SharePoint pour combler adéquatement ces besoins.

Conclusion

Cet article nous a présenté les notions de carte heuristique ainsi que la vue d’ensemble de l’architecture d’information dans un contexte SharePoint. Le prochain article couvrira le bloc 1 – Atelier de découvertes et le bloc 2 – Les besoins.

Le premier article de la série est disponible ici

Architecture d’information dans un contexte SharePoint – Partie I

Introduction

Je débute ici une série d’articles concernant l’architecture d’information dans un contexte SharePoint. Ces articles exposeront l’approche que j’utilise dans les projets SharePoint auxquels je participe. Cette approche est le fruit de mon expérience personnelle, de partage avec des ressources impliquées dans le domaine et de référence à certaines ressources reconnues dans en architecture d’information avec SharePoint comme Ruven Gotz, Richard Harbridge et Bob Mixon.

J’ai combiné l’utilisation de cartes heuristiques pour faciliter le travail de collecte et d’interprétation des informations durant la phase d’architecture de l’information et cette approche à fait l’objet d’un billet dans le blogue des MVP de Microsoft. Depuis la parution de cet article, je continue de raffiner et d’adapter mon ensemble de cartes heuristiques pour faciliter le travail d’architecture d’information.

Cette série d’articles va donc vous présenter les grandes étapes de mon approche en matière d’architecture de l’information dans un contexte SharePoint.

Définition

La définition traditionnelle de l’architecture d’information nous ramène vers les sites Web et l’organisation de l’information sur ces sites via l’aspect visuel, la navigation et la structure de haut niveau. Lorsque l’on applique l’architecture d’information dans un contexte SharePoint, il faut y ajouter des considérations propres à SharePoint comme les contenants (sites, pages, bibliothèques, listes, etc.) et les facilités offertes pour supporter l’architecture de l’information (types de contenu, métadonnées, etc.). C’est donc dans cette optique que mon approche a été développée et continue d’être améliorée.

Profil de l’architecte d’information

Idéalement, un architecte d’information doit avoir les habiletés suivantes:

  • Sens politique et négociation – Il n’est pas rare que certaines étapes de l’architecture d’information puissent prendre une tournure politique dans une organisation. L’architecte d’information doit alors être en mesure de négocier et d’agir en médiateur entre les diverses parties prenantes
  • Habiletés analytiques et techniques – Afin de s’assurer que les divers besoins sont adéquatement supportés par les bons artéfacts SharePoint, l’architecte d’information doit comprendre les implications fonctionnelles et techniques de chaque option proposée et être en mesure d’expliquer les choix proposés
  • Communicateur et facilitateur – Ces habiletés sont essentielles durant la phase de découverte et de collecte de besoins. L’architecte d’information doit être en mesure d’influencer les autres, de gagner leur confiance, de remettre en question les besoins d’une façon positive et de maîtriser l’art du compromis

L’architecte d’information est aussi un chef d’orchestre qui doit diriger une équipe multidisciplinaire composée d’experts en la matière (SME), d’architectes technologiques, d’architectes SharePoint et d’utilisateurs finaux. Il doit donc posséder un bon mélange de compétences techniques et fondamentales.

Concepts fondamentaux

Pour comprendre l’importance et la valeur d’une architecture d’information, il est important de connaître ces concepts fondamentaux: l’infobésité et l’indice de repérabilité. La compréhension de ces concepts permettra à l’architecte d’information de mieux conseiller les parties prenantes du projet. Voici un survol de ces concepts.

Infobésité

Ce terme désigne le fait que nous sommes de plus en plus inondés d’information de toute sorte et de toute provenance. Le vocable de « Surcharge Informationnelle » est aussi utilisé. Quelques symptômes de l’infobésité:

  • 30% des courriels sont inutiles
  • La gestion des courriel consomme plus de 30% du temps d’un gestionnaire
  • Les gens travaillant dans les départements de Vente passent moins de temps avec des clients et plus de temps avec des données…
  • On considère maintenant comme normal le fait d’avoir plus de 30 acétates dans une présentation

Les conséquences de l’infobésité sont diverses:

  • Délais dans la prise de décision car il faut attendre que tous aient assimilés la même information que nous
  • La prise de décision se fait souvent sans l’information appropriée
  • À force d’être submergé d’information, on adopte parfois une attitude de retrait
  • Beaucoup de gestionnaires croient que SharePoint va empirer la situation

Une étude réalise par le collège King’s de Londres a démontré que l’infobésité peut réduire le QI de dix (10) points alors que la consommation de marijuana peut réduire le QI de cinq (5) points…

Indice de repérabilité

Ce concept, initialement énoncé par Bill English, stipule que l’indice de repérabilité est le degré de facilité avec laquelle on peut retrouver de l’information dans un site Web. Il est très important de considérer ce facteur car il est prouvé que:

  • La plupart des utilisateurs ne savent pas exactement ce qu’ils recherchent
  • La plupart des utilisateurs ne savent pas comment effectuer une recherche
  • La plupart des utilisateurs n’ont pas de patience pour les systèmes compliqués

L’architecte de l’information doit donc toujours garder en tête le fait que toute organisation souffre, à divers degrés, d’Infobésité et que l’un des remèdes à cette maladie est de maximiser l’indice de repérabilité de l’information dans l’organisation.

Conclusion

C’est ici que se termine ce premier article sur l’architecture d’information dans un contexte SharePoint. Dans le prochain article, nous introduirons les cartes heuristiques qui nous seront d’une grande utilité dans la réalisation d’une architecture d’information.

 

Considérations de performance pour la fonction Réseautage social d’entreprise dans SharePoint 2013

Microsoft a publié récemment un guide vous permettant de comprendre les considérations de performance liées à l’utilisation de la fonctionnalité Réseautage Social d’Entreprise pour SharePoint 2013. L’article décrit en détails un essai de charge pour les fonctionnalités du volet Social ainsi que les conclusions à tirer de ces essais avec trois types de charge (10,000 usagers, 100,000 usagers et plus de 500,000 usagers).

Les grandes conclusions de cet article sont les suivantes:

  • Utilisation de disques physiques séparés pour la base de données des Profils (Profile DB)
  • Attribuer beaucoup de mémoire RAM (12 Gb) aux serveurs frontaux (WFE) pour supporter l’application de service User Profile
  • Attribuer beaucoup de mémoire RAM (12 Gb) aux serveurs contenant la cache distribuée

Tous les détails de cet essai se trouvent dans cet article publié sur MSDN.

 

 

Retour sur SharePoint Summit 2013-Québec

C’est avec grande satisfaction que j’ai reçu les résultats des évaluations de ma session ‘Architecture d’Information dans un contexte SharePoint’ que j’ai livré en avril dernier au SharePoint Summit 2013 de Québec. Je tiens donc à remercier particulièrement ceux qui ont pris le temps d’assister à ma présentation et compléter le formulaire d’évaluation.

Quelques points:

  • Maîtrise du sujet – 100%
  • Revoir le conférencier en 2014 – 93%
  • Sujet adapté au niveau de l’audience – 93%

C’est encourageant et ça incite à continuer de s’impliquer et de partager avec la communauté.  Merci!