Archives pour la catégorie Yammer

Réseaux Sociaux d‘Entreprise pourquoi et comment se lancer ?


Voici les slides du café iNext qui s’est déroulé à Genève le 26 juin 2014.

Une petite introduction :

Canal majeur du partage de l’information, les réseaux sociaux s’invitent naturellement dans le monde de l’entreprise. Cet événement, illustré par des cas d’usage, a pour objectif de décrire ce que doit être un réseau social d’entreprise (RSE), les changements induits, les freins à l’adoption, les principes de mise oeuvre et les facteurs de réussite. Quels outils peuvent être mis en oeuvre ? Sont-ils systématiquement délivrés en mode SAAS ? Nous parlerons de Yammer, leader mondial dans le domaine, mais aussi des fonctions sociales de SharePoint 2013 et des Add-Ons qui peuvent être utilisés tels que SITRION (anciennement NewsGator).

Yammer From Inside


logo yammer

Ce que vous trouverez ci dessous est un extrait des différentes sessions du « Getting Social RoadShow » qui a eu lieu à Issy Les Moulineaux dans les locaux de Microsoft le 2 Octobre dernier.

L’entreprise réactive

Par Ludovic MAGNE, Sales Executive Office 365, Microsoft.

Lors de la mise en œuvre d’un RSE les changements profonds suivant s’opèrent dans une entreprise :

  • Hiérarchie -> réseau
  • Contrôle -> mise en capacité
  • Carotte et bâton -> motivation intrinsèque
  • Client et partenaires ->  communauté

 Au sein du RSE il faut bien distinguer les notions suivantes :

  • Participation ET NON Consensus
  • Transparence ET NON Tout est public
  • Acceptation de l’échec ET NON Manque de responsabilité
  • Adaptabilité ET NON Pas de planification
  • Mise en capacité ET NON perte de leadership

Voilà les grands changements qui doivent s’opérer dans une entreprise qui tient à rester agile / réactive. Les t grandes idées du discours porté par Microsoft sont issues du site THE RESPONSIVE ORG.

L’IT garant de l’innovation et du succès d’un projet RSE

Par Stéphane SCHNEIDER (Office 365 Evangelist), Yann ARMAND (Software Engineer, Yammer), Laurent JOUANNEAU (Cloud Vantage Services)

Nouveau mode de déploiement 

Le type de déploiement d’un outil RSE est complètement différent de ceux que l’on connait classiquement. En effet tout est centré sur les utilisateurs :

  • Ils essayent l’outil
  • Ils l’adoptent ou non
  • Ils le partagent avec leurs collègues ou non

On doit expliquer au préalable l’intérêt pour le métier de l’utilisateur puis le laisser se faire son propre avis. L’outil se répand toujours rapidement dans ce mode déploiement, ensuite l’Entreprise reprend la main progressivement.

Nouveau mode de développement

Les équipes Yammer sont les 1er utilisateurs de leur outil ( DOG FOODING), ce qui apporte les avantages suivants :

  • Plus ils ont d’utilisateurs en interne, plus ils on de testeurs en conditions réelles et diversifiées, plus ils peuvent trouver et corriger les bugs rapidement
  • Lors des évolutions fonctionnelles ils ont un œil critique sur le produit, cela leur permet de garder une certaine cohérence afin de ne pas avoir un simple « amas » de fonctionnalités
  • ils n’utilisent plus l’email et pourtant ne ratent jamais une réunion

Les développements se font en mode LEAN (BUILD, MESURE AND LEARN) :

  • On construit et on déploie le plus vite possible
  • On mesure l’impact de la fonction déployée
  • On créé quelque chose d’autre en fonctions des mesures

Notion de MVP importante :

  • Minimum Viable product
  • ou Most Viable product
  • ou Minimum Valuable product
  • ou Most Valuable product

Ce qui implique qu’il faut aller à l’essentiel.

Par exemple lors de l’implémentation de la fonction de traduction automatique, les équipes n’ont pas cherché à traduire l’ensemble de la page mais sont restées centrées sur le besoin :

  • Ils détectent la langue de l’utilisateur courant et la langue du post qui est en train d’être consulté,
  • s’il n’est pas dans la langue de l’utilisateur, la traduction du post est suggérée
  • le moteur de traduction est BING

Tests avec la méthode A/B Testing. Les campagnes de tests durent 15 jours.

Les équipes déterminent le succès d’une fonctionnalité en fonction :

  • des mesures d’utilisation (si > 70% d’utilisation elle sera conservée par exemple)
  • analyse des réseaux et de leur « santé » et mesure d’impact de la nouvelle fonctionnalité

L’équipe Yammer ne conserve que 30 à 40% des fonctionnalités développées. Il y a 3 releases par semaine.

Ajouter des fonctions au produit c’est le rendre plus complexe pour les utilisateurs et pour les équipes Yammer concernant la maintenance.

L’équipe Yammer est constituée d’ingénieurs dont le métier est en relation avec l’architecture du produit, à savoir :

  • des ingénieurs FRONT END
  • des ingénieurs BACK END
  • des ingénieurs SERVICES
  • des ingénieurs QUALITE, SECURITE
  • des designers / ergonomes

Organisation projet

Pour chaque nouvelle fonction, un projet est lancé avec une équipe transverse qui doit s’auto-suffire. 2 à 10 personnes pour 2 à 10 semaines.

Parmi les ingénieurs il y en a un qui prend le rôle de techlead, ce rôle est mobile. Cette personne assure alors la communication externe du projet.

L’équipe, en auto gestion, doit être capable de prendre toutes les décisions.

Lorsque le projet est terminé, l’équipe est détruite. Personne n’a la paternité d’une fonction particulière (no ownership). Les ingénieurs partent alors travailler sur d’autres sujets, par défaut ils sont dans l’équipe support. Il y a ainsi très peu de chance qu’un ingénieur corrige ses propres bugs, ce qui oblige à écrire du code propre.

Les développeurs apprennent beaucoup en lisant le code des autres, il y a énormément d’échanges sur les bonnes pratiques.

Le découpage en petits projet permet d’éviter, alors que l’entreprise grossit, aux ingénieurs de s’éloigner des problématiques qui concernent les utilisateurs, cela permet d’éviter de trop se spécialiser également. Ils veulent conserver l’esprit start-up.

Les products manager assurent la cohérence globale du produit, leur rôle est central, ils initient le changement et doivent rester proche des utilisateurs.

Yammer doit rester simple et efficace.

Intégration avec le système d’information

La solution utilise OpenGraph  (développé à l’origine par Facebook) qui permet une interaction bidirectionnelle avec d’autres outils sur le modèle Acteur / Action / Objet.

D’une application métier vers Yammer : Possibilité de PUSH de données (tout type d’objet) en REST. Chaque activité apparaît dans le TICKER.

De Yammer vers une application métier : possibilité d’intégrer un flux Yammer (groupe, personne, tag ou tout objet Open Graph) dans une application. Disponibilité de boutons FOLLOW / LIKE dans les applications.

Côté authentification et gestion des utilisateurs :

  • Possibilité d’import de fichiers plat LDAP
  • Possibilité de connexion ADFS (Active Directory Federation Services).
  • Un mécanisme plus élégant dee SSO devrait voir le jou dès cet automne afin de permet une intégration plus forte avec le SI

Sécurité

Chaque client reste propriétaire de ses données et il est le seul à y avoir accès. Dans les rares cas où un employé Yammer est amené à intervenir sur des fichiers corrompus par exemple, celui-ci est assermenté pour le faire sur une durée déterminée. Chacune de ses actions est logguée dans le système ce qui évite toute fuite de données.

Les ingénieurs sécurité mènent une veille constante, ont accès au code Yammer et testent l’application en continu.

Côté infrastructure toute connexion au réseau est sécurisée en HTTPS. Des pare-feu sont en place avec des mécanismes de détection des intrusions. Les données sont séparées du reste de l’application.

Les DATACENTER Yammer sont certifiés SSAE16 SOC1, l’application est également certifiée et répond à de nombreuses exigences réglementaires, légales et infrastructure.

Souvent ce type d’application Cloud est bien plus sécurisée qu’une application hébergée OnPremise par une Entreprise dont ce n’est pas la fonction première.