Le cadrage du projet de Réseau Social d'Entreprise

Dans un billet précédent j'évoquais la typologie des projets et l'adaptation possible de la méthodologie au type de projet. 

Je  considère que la phase de cadrage précède en général celle du cahier des charges mais peut suffire à un projet expérimental. Il est souhaitable d'aborder le cadrage avec le chef de projet et si possible quelques représentants de la Maîtrise d'Ouvrage à partir d'une liste pré-établie (mais adaptable) d'environ 70 à 100 questions. Cette approche est valable lorsque les usages prévus(au sens Métier) sont connus et qu'un premier périmètre du projet a été esquissé. 

Les sujets suivants doivent être abordés pendant la phase de cadrage :

• Le contexte et la culture d'entreprise
• Les enjeux, objectifs et ROI du projet
• Les éléments méthodologiques du projet 
• La gouvernance dont peut bénéficier le projet 
• Les aspects Métier (fonctionnalités, processus, organisation, changement)
• L'intégration au SI (urbanisation, contraintes, risques…)

Le contexte et la culture d'entreprise

L'entreprise a l'habitude de manager par projet, par objectifs et de faire participer les collaborateurs à la définition de la stratégie  

Il existe une expérience en termes de travail collaboratif que ce soit en interne ou avec des partenaires 

Le télétravail a déjà été expérimenté  : avec quelle ampleur ? (nombre de salariés et de sites concernés, type d'outils utilisés…) 

La gestion de communautés (community management) est déjà pratiquée dans l'entreprise ou connue de certains collaborateurs  

Les enjeux, objectifs et ROI du projet

Les enjeux ont été formulés, communiqués et sont en rapport avec les valeurs de l’entreprise
Des objectifs Spécifiques, Mesurables, Accessibles, Réalistes, Temporels ont été formulés et validés
Le retour sur investissement (ROI) du projet a été évalué sur des bases précises

Les éléments méthodologiques du projet 

Le chef de projet a une expérience du management transverse, de la gestion de projet et des outils collaboratifs

Les leaders du groupe ont une expérience du management transverse, de la gestion de projet et des outils collaboratifs

La méthodologie envisagée est formalisée (go/no go, recette )

Le planning est établi sur des bases réalistes et comprend des marges de manœuvre

Les intersections avec d'autres projets ont été identifiées 

La gouvernance dont peut bénéficier le projet 

Les modalités et les indicateurs de pilotages sont identifiés 

Les facteurs de succès ont été formalisés

Les risques d'échec du projet RSE sont identifiés ainsi que les parades 

Les aspects Métier (fonctionnalités, processus, organisation, changement)

Les besoins ont été analysés et font l'objet d'une liste de fonctionnalités requises

Les impacts sur les processus de l'entreprise ont été mesurés

Les impacts sur l'organisation (acteurs et rôles) ont été évalués

Un plan d'accompagnement du changement a été établi 

L'intégration au SI (urbanisation, contraintes, risques…)

Le projet RSE peut ou doit être intégré à un schéma d'urbanisation

Les liaisons ou flux du RSE avec les autres applicatifs de l'entreprise ont été identifiées 

Les contraintes du SI au regard du projet RSE sont connues

Les risques que l'entreprise souhaite gérer sont identifiés

Les réponses aux questions détaillées sont notées, pondérées puis totalisées selon les axes évoqués ci dessus. Le résultat est exprimé graphiquement et doit faire l'objet d'un débat avec la Maîtrise d'Ouvrage afin de consolider le projet voire de modifier sa configuration.

Je reviendrai plus en détail lors de futurs billets sur certains de ces éléments et en particulier le calcul du ROI.

Le projet de Réseau Social d'Entreprise : au delà des fonctionnalités

En résumé...
La conduite d'un projet de Réseau Social d'Entreprise ne se résume pas à remplir une grille de fonctionnalités mais doit s'accompagner d'une démarche de gestion de projet adaptée.



En détail ...
Ma recommandation est d'intégrer dans la réflexion, le format du projet selon une typologie basée sur 2 axes : amplitude fonctionnelle et nombre d'acteurs impliqués (voir billet précédent). 

Cette approche du projet doit également s'appuyer sur une attitude agile car le projet peut s'inscrire dans une dynamique d'évolution où, du stade "Expérimental", il  pourrait devenir "Collaboratif" ou "Spécialisé" avant de passer au stade "Étendu".

Cette réflexion nous rapproche également de  la  notion  de prototype ou POC (Proof Of Concept) qui ne sera pas sans intérêt pour évaluer un ROI. 


A titre d'exemple, dans un projet initialement Expérimental où les responsables Qualité d'une grande entreprise multi-sites échangeraient sur leurs bonnes pratiques, puis dans une extension de type Collaboratif mutualiseraient leur modélisation de processus, supports de sensibilisation internes ..., l'implication de tous les collaborateurs dans la démarche Qualité pourrait devenir ensuite un axe majeur du RSE Étendu. 

J'espère démontrer ici que l'adéquation fonctionnelle d'un outil à un besoin  peut difficilement être analysée sans appréhender le projet dans son ensemble  et en particulier ses perspectives d'évolution. 


Le premier périmètre fonctionnel peut être minimaliste et une approche agile permettra son extension progressive, quitte à changer de solution technique dans un deuxième temps (d'où l'intérêt du mode SaaS). 
Plus le spectre fonctionnel s'enrichira (projet Étendu) et plus l'intérêt d'un cahier des charges robuste sera marqué. 


Le schéma ci dessous illustre quelques points de vigilance pour chacun  type de projet. 

Dans un projet Expérimental, le mode SaaS est vraisemblablement de rigueur, une note de cadrage (gouvernance, enjeux, objectifs ...) pourra suffire sans pour autant nécessiter un cahier des charges fonctionnel lourd, le suivi du groupe projet et la formalisation du retour d’expérience permettront de passer à un stade plus engagé. Dans la version Spécialisé, la mesure des accès et des contributions devra être réalisée et s'accompagner d'une communication soutenue puisque d'emblée, le RSE est ouvert à un nombre important d'acteurs. Un projet Collaboratif nécessitera un cahier des charges plus robuste et vraisemblablement un accompagnement du chef de projet confronté immédiatement à une certaine complexité fonctionnelle. Le projet Étendu cumule toutes les vigilances (pilotage, accompagnement, planning...) jusqu'à l'éventuelle intégration au SI et à des applicatifs spécialisés (CRM, ERP, SSO...).


Même s'il passe par des phases intermédiaires (expérimentation, prototype...) et se construit progressivement dans un optique agile, un projet de Réseau Social d'Entreprise, est obligatoirement stratégique car il touche à la productivité des collaborateurs, l'ambiance de l'entreprise, ses avantages concurrentiels ...Il doit donc s'inscrire dans une réflexion prospective et bénéficier le plus rapidement possible d'un cadrage attentif. 
Je développerai l'intérêt et le contenu d'un cadrage dans un prochain billet. 

Réseau Social d'Entreprise : une typologie des projets

En résumé ...
Les projets de Réseau Social d'Entreprise sont différents et nécessitent une méthodologie puis un choix d'outil adaptés à certaines de leurs caractéristiques. Le nombre d'acteurs impliqués et l'amplitude fonctionnelle permettent de dresser une typologie et un mapping à 2 axes.




En détail ...
Si l'on accepte la définition par laquelle un Réseau Social d'Entreprise est une plateforme comprenant des fonctions de collaboration sociale et une ergonomie qui lui donnent une dimension "user-centric", la question de la gestion du projet (cadrage, expression de besoins, choix d'une solution, mise en oeuvre et accompagnement du changement) ne se pose pas en termes identiques pour toutes les initiatives. 


Face à l’intérêt que suscite actuellement les RSE, je suggère de bien adapter la méthodologie au type de projet  et propose une typologie sur 2 axes :

1. Le niveau d'usage exprimé en nombre d'utilisateurs et éventuellement de Directions Métier concernés par le projet de RSE. Le niveau bas de cet axe correspond à un projet limité à quelques acteurs et le point haut à un RSE ouvert au plus grand nombre.
2. L'amplitude fonctionnelle qui permettra de distinguer des projets de RSE aux fonctionnalités limitées en nombre de ceux qui d'emblée couvre un périmètre fonctionnel collaboratif large (voir billet sur le référentiel fonctionnel) 

Ce mapping permet de faire ressortir 4 types de projets de RSE :

• Expérimental : il pourrait également être qualifié d'hyper spécialisé car il concerne peu d'acteurs et un nombre restreint de fonctions. Cependant nous retenons "expérimental" qui laisse augurer d'une ouverture ultérieure assez logique compte tenu de la dynamique de communication sous-tendue dans un RSE. Exemple: mise en place d'une veille concurrentielle à l'usage de quelques responsables commerciaux ou membres d'un comité de direction. 
• Spécialisé : toujours limité en fonctions mais ouvert à un plus grand nombre d'acteurs. Exemple: redonner une dynamique à un SMQ (Système de Management de la Qualité) et faciliter la collaboration sur la modélisation des processus, augmenter le repérage des non conformités...
• Communautaire : un périmètre fonctionnel plutôt large pour un nombre restreint d'acteurs générant un RSE presque confidentiel, éventuellement dédié à des experts. Ce projet peut également comprendre une dimension expérimentale. Exemple: faire collaborer les responsables sécurité des différents établissements d'une entreprise multi-sites afin de mutualiser leur pratiques, d'échanger leurs contacts, de co-produire les procédures etc...
• Étendu : beaucoup d'acteurs et de nombreuses fonctions collaboratives. Exemple: mise en relation des membres d'un réseau de franchise et des collaborateurs du franchisé (avec vraisemblablement des niveaux d'accès différenciés) afin de faciliter la connaissance des nouveaux membres, les expertises individuelles disponibles dans le réseau, les services du franchiseur, la préparation des actions commerciales...

La méthodologie idéale et le choix d'outil qui en découlent pourront être différents selon le type de projet pressenti. Dans un projet expérimental l'outil pourrait ne pas être définitif, considérant que c'est un premier retour d'expérience qui permettra le cadrage du projet et que la capitalisation principale s'effectuera sur les comportements. A l'opposé, dans un projet étendu, l'intégration au SI pourrait être un facteur essentiel et le choix de l'outil devra être définitif imposant notamment une expression de besoins plus formalisée. 

Je développerai dans le prochain billet les recommandations méthodologiques associées à  chacun des ces types de projets RSE.

Expérimenter le Réseau Social d'Entreprise

La mise en place d'une période de test ou expérimentation d'un RSE n'est pas difficile à négocier avec un éditeur. La plupart d'entre eux, propose d'emblée 30 jours d'essai gratuit et si votre projet est réel, vous n'aurez aucun mal à négocier 2 ou 3 mois d'usage gracieux. 


Toute expérimentation qui se contenterait de mettre à disposition un RSE pendant quelques semaines sans un véritable plan d'animation risque fort de ne rien apporter. Nous sommes ici au delà de la phase qui a permis d'établir une shortlist de fournisseurs après avoir vérifié l'adéquation à une expression de besoins. Il s'agit maintenant de réaliser une expérimentation sur un outil a priori satisfaisant et d'impliquer un nombre significatif de collaborateurs avec les objectifs suivants :

• Mesurer l'adhésion des personnes aux objectifs du projet
• Evaluer l'appétence pour un Réseau Social d'Entreprise
• Identifier les contraintes organisationnelles 
• Evaluer l'interface de l'outil et sa navigabilité 
• Repérer les périmètres et fonctions prioritaires 

En pratique, vous  réaliserez votre expérimentation pour un projet réel, avec une équipe, un budget et un pré-choix de solution.

L'expérimentation vous permettra de poursuivre votre cadrage et d'aboutir à une vision clarifiée des éléments suivants :

• Le contexte et les points de culture d’entreprise sur lesquels prendre appui
• Les enjeux, objectifs et ROI du projet
• Les éléments méthodologiques du projet (acteurs, rôles, planning ...)
• La gouvernance dont doit bénéficier le projet 
• Les aspects Métier (fonctionnalités, processus, organisation, changement)
• L’intégration au Système d'Information de l'entreprise

L'expérimentation pourra être découpée en 3 phases : 

1-Phase de préparation 

A partir d'exemples réels fournis par l'éditeur ou identifiés lors de votre benchmark initial, il faudra déterminer un périmètre de tests (communautés, contenus, personnes ...) et nommer un chef de projet ou leader de l'expérimentation. Un support présentera la vision du RSE cible afin de situer le périmètre de tests dans le projet final. Un plan d'actions devra préciser les étapes et rôles attendus des différents acteurs.

2-Phase d'usage 

Le RSE expérimental sera ouvert avec un scénario d'animation  et un plan de communication dédié aux testeurs. Le scénario d'animation est un élément clé   afin que l'intérêt soit soutenu pendant toute la période d'expérimentation que je suggère de limiter à quelques semaines.  

3-Phase de bilan

L'usage d'un questionnaire facilitera une analyse objective et consolidable des avis mais des entretiens individuels ou par petits groupes permettront également un bilan qualitatif de l’expérimentation. 

Le bilan de l'expérimentation doit permettre d'apprécier les points suivants :

• La mesure de l’adhésion aux objectifs du projet
• L’appétence des utilisateurs pour un outil de type RSE collaboratif 
• Les contraintes perçues et leur mesure réelle 
• L’évaluation de l’interface de l’outil (facilité de navigation)
• L’évaluation des fonctions de l’outil (blog, forum, microbloging) 
• Les contraintes organisationnelles et techniques 
• Les facteurs de succès 

Ainsi conduite, l’expérimentation accompagnera avec intérêt la finalisation du dossier de cadrage  du projet.

Le rôle majeur des DSI dans les projets RSE

Séduites par la capacité des RSE à favoriser les échanges entre les acteurs, de nombreuses Directions Métier ou Support (RH, Communication) formulent des demandes de solutions de type RSE.

• Quels facteurs soutiennent cette évolution ?
• Quels sont les impacts sur le SI de l’entreprise ?
• Quel est le rôle de la DSI ?

Les utilisateurs finaux demandent plus de mobilité, d’ergonomie et de transversalité et les tendances suivantes se renforcent :

• L’usage personnel des réseaux sociaux y compris en mobilité qui contribue à une culture de la publication centrée sur les personnes et les communautés davantage que sur les documents.
• Des concepts d’interface qui deviennent incontournables : ma page ou mon profil, mes communautés ou mes groupes, le fil d’activités ou timeline … que les utilisateurs s’attendent désormais à retrouver dans leurs outils professionnels.
• Une appétence pour des échanges moins hiérarchiques, moins structurés et plus transverses.

Souvent en mode SaaS et d’un coût acceptable, les solutions de RSE peuvent se mettre en œuvre rapidement et risquent de se multiplier au sein d’une même entreprise reproduisant ainsi les silos décriés.

Bien que la tendance soit encore timide, les projets de RSE les plus évolués tentent d’intégrer des liens avec d’autres briques du SI de l’entreprise (CRM, ERP, bureautique…).

Les projets de RSE comportent des enjeux intéressants pour le SI des entreprises, comme par exemple :

• Apporter de la valeur ajoutée à l’urbanisation du SI (par exemple en valorisant l’accès à certains contenus et aux applicatifs qui les supportent tel que la GED).
• Ne pas altérer le niveau de sécurité du SI (fiabilité du mode SaaS, lien éventuel entre RSE et Réseaux Sociaux publics).
• Lier le RSE aux processus métier et contribuer à une augmentation de la productivité.

La DSI a un rôle majeur à jouer dans les projets de RSE même si les Directions Métiers semblent pouvoir être très facilement autonomes avec les solutions SaaS du marché. Les DSI devront notamment :

• Détecter le plus en amont possible les  projets  RSE
• Définir les interactions futures entre le  RSE et les autres briques du SI (CRM, ERP, bureautique…) : urbanisation autour du RSE.
• Accompagner les utilisateurs dans un cadrage de leurs projets de RSE  qui respectent leurs objectifs mais intègrent également les contraintes du SI.
• Proposer ou valider des solutions technologiques qui tout en conservant la valeur ajoutée du RSE contribueront à la cohérence du SI.
• Réaliser des prototypes avec les Directions Métier et formaliser les retours d’expérience.
• Définir avec les Métiers les indicateurs pertinents pour la mesure du retour sur investissement.

Mi-temps dans le match "ROI des RSE" opposant visionnaires et "brick and mortar"

Le retour sur investissement (ROI) des réseaux sociaux est-il mesurable ? 

N'y aurait-il pas sur cette question un peu de parti pris entre fervents de l'internet 2.0 et plus (la réalité augmentée, le big data) et des dirigeants d'entreprise "un peu coincés" qui répondraient inlassablement "Combien cela me rapportera t-il ?"

Quand Gary Vaynerchuck, à la question "What is the ROI of Social Network ?" répond "What is the ROI of your mother ?" il entend soutenir sa vision et on le comprend ! Lorsqu'un dirigeant s'enquiert de la valeur d'un projet et des risques potentiels de perturbation dans l'équilibre social de l'entreprise, il fait son job de patron. 

Il est peut-être temps de siffler la mi-temps de ce match anachronique : "Etre visionnaire n'oblige en rien à ignorer toute mesure de la valeur" !

Avec un groupe de dirigeants et d'experts, nous avons travaillé sur cette question et vous livrons nos réflexions dans un livre blanc "Mesurer la valeur et le ROI d'un projet de Réseau Social d'Entreprise".

Quelques principes ont été retenus pour cette réflexion :

• Le champ d'analyse  est le Réseau Social d'Entreprise et non les Réseaux Sociaux (publics)
• Nous parlons "Valeur" et pas uniquement "Finances"
• La contribution aux enjeux stratégiques (de l'entreprise, pas du projet) est un élément clé
• Nous sélectionnons des usages et non des technologies 

Par conséquent, l'ambition de ce livre blanc est de proposer (enfin !) une méthode normée qui réconcilie l’approche purement financière du ROI, les dimensions qualitatives et la notion de risque, le tout en alignement avec les enjeux stratégiques de l’entreprise.

Il  est dédié aux décideurs d’entreprises, associations et autres organisations qui doivent statuer sur un projet de Réseau Social d’Entreprise. Il peut également aider les chefs de projets à préparer leur note de cadrage lors de l’étude préalable.

Pour télécharger le Livre Blanc, cliquez ici  

Pour contribuer à ces travaux, rejoignez le groupe LinkedIn 

Quels usages "Métier" du Réseau Social d'Entreprise

Au delà du web 2.0, de l'entreprise 2.0 et autres concepts 2.0, la question se pose parfois d'identifier les usages Métier et concrets d'un Réseau Social d'Entreprise. Une des difficultés provient d'un mélange des genres  notamment entre enjeux, usages et fonctionnalités.
Or, ne confondons pas les enjeux, les usages et les fonctionnalités. 
Paul Valéry disait "Les mots n'ont pas de sens, ils n'ont que des valeurs", donnons leur donc une valeur ou un sens. 


Les enjeux 

Les enjeux sont les gains attendus exprimés globalement et souvent mis en perspective avec la stratégie de l’entreprise. Ils expriment une tendance sur un axe mais rarement quantifiée, ni précisée dans le temps. Ils seront ultérieurement complétés par des objectifs S.M.A.R.T. 
Exemples :

• Augmenter la productivité 
• Diminuer le turn-over 
• Améliorer la communication avec les clients 
• Diminuer le délai de réponse pour les offres commerciales 

Ces exemples montrent bien l'impossibilité de choisir un outil ou mesurer un ROI à partir d'une simple expression des enjeux et l'intérêt d'un cadrage du projet. 


Les usages 

L’usage renvoie à l’emploi courant ou habituel qui est fait d’une chose et  se réfère donc à l’utilisation ou au « Métier ». Il permet à l'usager d’atteindre un objectif particulier. A l'idéal, il pourra être positionné sur la cartographie des processus même s'il est transverse à plusieurs processus. 
Exemples :

• Intégrer des stagiaires et des nouveaux salariés 
• Affecter des demandes clients à des experts internes 
• Coproduire des offres commerciales avec des partenaires 
• Partager des bonnes pratiques 

L'usage sera satisfait par une ou plusieurs fonctionnalités.

Les fonctionnalités 

La fonctionnalité est l’expression du service apporté par une application informatique. Elle se réfère à l'outil. S'agissant des plateformes collaboratives et sociales, nous avons identifié 130 fonctionnalités regroupées en 35 fonctions, elles mêmes issues de 6 axes fonctionnels. 

Exemples :

• La plateforme permet de dialoguer en ligne avec d'autres utilisateurs 
• La plateforme permet de réaliser des questionnaires interactifs (choix multiples…) 
• La plateforme permet de définir des formulaires que les utilisateurs peuvent remplir en ligne 
• Les contenus peuvent être associés par les utilisateurs à des étiquettes (tags) qui leur sont propres

La  réflexion est toujours itérative, car les fonctionnalités d'un produit peuvent encourager de nouveaux usages et faire émerger progressivement de nouveaux enjeux. Cependant une réflexion initiale indépendante sur ces 3 axes permet de mieux cerner :

• Le pourquoi (les enjeux)
• Le quoi (les usages) 
• Le comment (les fonctionnalités) 

Forts de cette clarification, les porteurs de projet de type Réseau Social d'Entreprise seront mieux armés dans la négociation des budgets et des conditions de succès à mettre en place.

Comment choisir une solution de RSE ?

Comment choisir une solution de RSE parmi une offre qui répertorie environ 90 produits (plus de 50 solutions propriétaires et près de 40 en Open Source) ? 


Ce sujet a été débattu lors  d'une table ronde au salon Intranet 2.0 et RSE de la Porte de Versailles le 13 mars 2012 animée par Yves Grandmontagne (Journaliste indépendant) avec les intervenants suivants :

• Arnaud RAYROLE , Directeur général, LECKO
• Maxime VIGNON, Associé fondateur, NEXENTURE / MY LIVE COMPANY
• Alexandre MERMOD, CEO, CALINDA SOFTWARE
• Pauline JOSNIN, Chargée de Marketing et Communication, CNEH
• Hervé BEBIN, Directeur Associé, SDE CONSULTING

Ma recommandation méthodologique est de procéder en 3 étapes :

1. Déterminer les contraintes du projet 
2. Identifier les majeures fonctionnelles
3. Construire sa grille de décision

1- Déterminer les contraintes du projet  


Il est possible que votre projet soit soumis à des contraintes particulières et dans ce cas, votre champ d'analyse pourra être réduit aux solutions satisfaisant ces contraintes. La politique informatique de l'entreprise peut en effet imposer par exemple :

• Un hébergement interne ou en cloud privé
• Une solution Open Source 
• Une compatibilité avec d'autres environnements informatiques 
• etc...

Cette première étape identifie les solutions compatibles. Même s'il est bien rare de ne disposer d'aucune contrainte dans un projet, il est possible de faire le raisonnement global une première fois sans contrainte puis de ré-injecter les contraintes dans un deuxième temps. L'avantage est dans ce cas ne pas trop fermer le champ dans l'hypothèse où certaines contraintes seraient "négociables".


A l'issue de cette étape, on pourra , par exemple, décider de travailler exclusivement sur des solutions en mode SaaS hébergées en clould public. Ce choix peut convenir à une entreprise ne souhaitant gérer aucun environnement technique et mettre en oeuvre le projet dans un délai très court.


2- Identifier les majeures fonctionnelles


Même pour les "pure players", les produits de RSE ont souvent une dominante fonctionnelle (conversationnelle, documentaire...). Dans sa dernière étude sur le marché des RSE, Lecko  propose une approche dite "de mise en scène en briques fonctionnelles" ou "de mise en scène conversationnelle". Chacune de ces 2 approches sélectionne un ensemble de produits. 
Dans un billet précédent de ce blog, j'avais proposé de situer le projet sur les dominantes fonctionnelles suivantes :

• Collaboration sociale (profil, mur, tableau de bord, contacts sociaux...)
• Echanges distants synchrones (messagerie instantanée, vidéoconférence...)
• Edition et publication de contenu (portail, blog, wiki, forum, flux...)
• Partage documentaire (fichiers et documents, recherche, versioning ....)
• Gestion de projets (ressources, planning, workflow, risques...)
• Organisation et bureautique (messagerie, contacts, agenda, tâches, édition de documents)

La réalisation de cette deuxième étape, si elle associée à une intégration de contraintes doit permettre de restreindre l'analyse à une douzaine de produits voire moins si les contraintes initiales sont fortes. 


3- Construire sa grille de décision 


Je recommande de penser "Projet" dans son ensemble plutôt que "Cahier des charges fonctionnel détaillé" et de réfléchir davantage en "Usages" qu'en "Fonctions". Si l'approche "user-centrique" des RSE et les fonctionnalités  de type conversationnel ont ouvert la voie à de nouveaux usages, il n'en demeure pas moins qu'un usage cible trouvera parfois plusieurs réponses fonctionnelles possibles. 
Par exemple, la conversation entre membres d'un réseau peut s'appuyer sur le fil d'activités, sur des messages internes au RSE (instantanés ou non), sur des commentaires associés à d'autres éléments (billets de blog, fichiers, tâches...). 
Autre exemple : la mise à disposition de documents peut trouver sa réponse dans la publication de fichiers (édités par une autre source puis chargés dans le RSE) mais également dans l'intégration d'un lien vers un système d'édition en ligne tel que Google docs ou encore un lien vers un répertoire hébergé  tel que Dropbox.


La grille de décision pourra être construite comme une série de critères notés et pondérés. On regroupera ces critères dans les familles suivantes :

• La réponse aux enjeux majeurs du projet (eux même identifiés dans une phase de cadrage initial) pour 20 à 30%  de la note globale.
• La réponse aux usages identifiés dans l'expression des besoins  pour 30 à 40% de la note globale (1 critère par usage majeur).
• Le fournisseur, son offre d'accompagnement, sa pérennité, sa stratégie d'évolution pour 20 à 30 % de la note globale.
• Le budget (logiciel, hébergement, intégration...) pour 20 à 30 % de la note globale.

 Certains paramètres tels que le potentiel d'intégration , l'ergonomie ou les performances trouveront leur place soit dans la réponse aux usages soit dans les contraintes initiales et dans certains cas dans les deux.

Le RSE idéal existe t-il ?

L'usage d'un  RSE est souvent  précédé d'une phase  d'utilisation des médias et réseaux sociaux (LinkedIn, Viadeo, Facebook, Twitter pour ne citer que ceux-ci) et votre compte RSE vient s'ajouter à une liste parfois déjà longue. Et, au delà du réseau de votre entreprise, il est souvent nécessaire d'intégrer plusieurs réseaux collaboratifs étendus : celui de votre éditeur, votre groupement professionnel, des partenaires ... Le résultat est donc une multiplication des comptes, d'autant que la plupart des solutions offrent également des accès mobiles sur tablettes et smartphones. Cette gestion n'est pas négligeable.

Par ailleurs,  la mise en place d'un RSE dans l'entreprise est rarement la première brique du système d'information et celui-ci doit s'intégrer aux applications déjà en place : messagerie, CRM, GED, KM, SIRH...

Il est donc tout à fait possible de se retrouver face à des questions comme celles-ci :

• Comment informer des partenaires d'une information présente dans le RSE alors que ces derniers n'en font pas partie ?
• Comment transmettre à des collaborateurs ou collègues des informations issues d'un média social (Twitter par exemple) alors qu'ils en sont absents ?
• Comment publier et maintenir une information unique vers des membres de différentes communautés dans un RSE ou des membres de différents RSE (du même éditeur ou de plusieurs éditeurs) ? 
• Comment transférer une information reçue en messagerie dans un autre environnement ?
• Comment automatiser certaines opérations (exemple: je tweete au quotidien et j'informe mes collaborateurs par un récapitulatif hebdomadaire) ?

Dans la réalité, la liste des questions est plus longue et il serait vain de croire que le nombre de solutions disponibles va se réduire. Bien au contraire, l'offre s'étoffe de jour en jour et il y aura toujours de bonnes raisons d'ajouter tel ou tel outil dans la panoplie et d'ouvrir de nouveaux comptes dans d'autres environnements. 

La réduction du nombre de mails, dont certains pensent qu'elle est un objectif obligatoire de tout projet RSE, pourrait presque paraître accessoire si des réponses n'étaient pas apportées aux questions ci dessus.

L'offre du marché évolue-t-elle dans le sens d'une interopérabilité ?

La réponse à cette question (ancienne comme l'informatique) dépend notamment des équilibres commerciaux : les petits éditeurs doivent assurer leur compatibilité avec certains leaders, les grands éditeurs rachètent les solutions qui leur sont complémentaires et tentent de maintenir une base de clients captifs ...

Ces équilibres évoluent en permanence et les entreprises doivent être vigilantes sur les points suivants :

• Définir les processus cibles et baliser les usages avec des bonnes pratiques. Malgré l'idée assez répandue que les RSE véhiculent principalement une information non structurée, il est indispensable de formaliser la position du RSE dans certains processus métier afin d'éviter les pratiques divergentes et les sources de dispersion.
• Privilégier les solutions s'appuyant sur des standards et des collaborations fortes entre éditeurs pérennes. 
• Mettre à jour le schéma d'urbanisation du système d'information en intégrant le RSE afin d'éviter les redondances fonctionnelles et de ne pas perdre ses utilisateurs. 

À défaut d'un RSE idéal capable de gérer tous les environnements et toutes les situations, des solutions  d'interface ont leur raison d'être.  Le développement du mode SaaS et de certains standards techniques ainsi que le caractère incontournable de certains outils (qui peut ignorer Outlook, Facebook, Twitter, Google ...) génèrent des utilitaires parfois remarquables.

Regardons par exemple if this then that  qui offre la possibilité de générer des automatismes entre 50 applications différentes (gmail, Google calendar, Evernote, LinkedIn, Delicious, Buffer, Twitter, Facebook ...). 

Certes, les actions automatisées sont basiques : lire un événement, créer un tweet, ajouter une note. Cependant tout consultant ou informaticien rompu aux problématiques des APIs appréciera l'efficacité et la simplicité de l'interface. 
Dans le même genre de service, voir aussi zapier décrit dans l'excellent blog de Descary 
Cet exemple transposé au système d'information de l'entreprise pourrait nous faire rêver quant à la simplicité d'intégration et nous interroger sur la voie à suivre dans l'évolution du SI de l'entreprise pour y développer la collaboration, la transversalité, la sérendipité...

En effet vaut-il mieux privilégier :

1. Une solution de RSE pivot de cette évolution qui s'articule avec les autres  briques applicatives (ERP, GED, CRM ...)
2. La reconversion d'une brique historique dans une version "socialisée" servant de pseudo RSE et s'articulant avec les autres applicatifs
3. Une "socialisation" du SI par le développement de connections ad hoc entre les briques applicatives

La décision de privilégier l'une où l'autre hypothèse s’appuiera sur plusieurs paramètres : le schéma actuel  d'urbanisation et les évolutions envisagées, l'ampleur du projet RSE et la vitesse de déploiement souhaitée, le niveau de risque acceptable face à des solutions innovantes, les roadmaps des éditeurs pour les briques déjà en place ... 

Difficile ne pas consacrer au moins quelques journées hommes à la réalisation d'un dossier de cadrage afin d'analyser ces différentes questions.