Intégrer réseaux sociaux et outils métiers : à quoi pensent les éditeurs ?

En deux mots: réseaux sociaux et  outils métier, sont les deux faces complémentaires du travail de chacun et les logiciels motorisant l’un et l’autre doivent faire disparaitre la barrière artificielle qui existe entre les deux. Les éditeurs s’y emploient mais certaines approches de l’intégration social/métier montrent une incompréhension totale des besoins de l’utilisateur final.

Pensée encore hérétique il y a trois ans, il est désormais devenu évident que le monde « social » et le monde des processus ne sont pas deux alternatives entre lesquelles il faut opérer un choix mais deux faces du travail entre lesquelles il faut développer complémentarité et synergies.

L’idée est relativement simple : les applicatifs métiers donnent la marche à suivre et contiennent les problèmes ou éléments autour desquels la collaboration est nécessaire (le networking étant un catalyseur de collaboration mais ne s’y substituant pas). Les outils « sociaux » sont les endroits où l’on trouve personnes et informations permettant de résoudre le problème, prendre une décision et organisation les échanges dans le but d’y parvenir. D’un strict point de vue utilisateur il est donc inconcevable de devoir jouer le rôle de middleware humain, de prendre les informations dans un outil, aller dans un autre pour les partager et en parler, revenir dans le premier mettre la solution en place…sans même parler des questions de transfert de données et d’information entre l’un et l’autre. Un vrai casse tête qui explique pourquoi le centre de gravité du poste de travail n’a que peu migré vers les plateformes sociales, le collaborateur préférant rester « où les choses se passent » plutôt que s’embarquer dans des pratiques énergivores.

L’inévitable socialisation des outils métiers

D’ailleurs même IDC le dit :

« By 2020, we won’t be talking about social applications because all applications have to be social, » (Michael Fauscette)

Confirmation chez IBM (même source) :

« Social becomes less about seeing a notification and liking it and more about gathering information, using it to participate in a process and creating leadership » (Kevin Cavanaugh)

Et même son de cloche chez SAP

It’s a combination of focus on infusing social activities into business processes, drawing in the right people to collaborate on relevant business activities, and then dealing with exception-handling and collaboration planning in more efficient and effective ways than in the past.

C’est donc une tendance forte ces dernières années. Il faut intégrer social et applications métier donc allons y.

Pour y arriver trois grandes tendances se dessinent.

Socialiser l’outil métier ou ramener le métier dans les réseaux sociaux ?

- socialiser les applicatifs métier : c’est la voie des éditeurs historiquement présents dans la sphère des applicatifs métiers. Salesforce a ouvert la voie en partant du CRM, Oracle puis SAP plus récemment suivent cette direction. Partant du principe que l’objet de la collaboration est la résolution de problème et la prise de décision autour d’un événement ou élément faisant partie de processus, le principe (très rapidement résumé)  est d’apporter les fonctionnalités collaboratives, conversationnelles et sociales autour de ces éléments qui sont par définition dans leurs applicatifs historiques.

- ramener l’action métier dans les réseaux sociaux: c’est la voie aujourd’hui choisie notamment par IBM au travers de ce qu’ils nomment l’ »embedded experience » que l’on se risquera à traduire par « expérience intégrée ». Ici l’événement et l’information de l’applicatif métier s’affichent dans le contexte de la plateforme sociale (réseau ou client mail de dernière génération) de manière « actionnable ». Et c’est ce caractère actionnable qui fait la différence.  Autrement dit l’utilisateur peut depuis sa plateforme sociale opérer une validation, rentrer ou modifier des données, réaliser des actions sans avoir à changer d’outil. On est donc  dans l’intéropérabilité. L’information métier est donc visualisable et actionnable dans le contexte social, peut servir de base à une conversation, un échange etc..

- amener l’alerte métier dans les réseaux sociaux : lorsque quelque chose se passe dans l’applicatif métier, le collaborateur est alerté dans son réseau social. Cela lui permet d’y rester sans crainte de rater quelque chose d’important et contribue à déplacer le centre de gravité de son poste de travail. Ce qui est une chose dont on ne peut que se féliciter car avant de découvrir et développer peu à peu de nouvelles manières de faire encore faut il que le collaborateur « soit » dans l’outil en question et soit en quelque sorte « exposé » à la nouveauté. Quand l’alerte arrive, il n’a qu’à cliquer sur le lien, se logger si nécessaire dans l’outil métier, faire son travail et revenir. C’est la voie empruntée par tous ceux qui n’ont pas choisi une des deux précédente. L’essentiel du marché. Et il ne se passe pas un mois sans qu’un acteur annonce fièrement sa capacité à proposer de telles intégrations dans ses produits. Ce qui est une excellente chose pour les raisons évoquées plus haut et se traduit par une vague d’enthousiasme de l’écosystème et un certain « effet Wow ! »

Heu…attendez une minute.

Les éditeurs réinventent l’alerting en 2013 et on applaudit

Depuis combien de temps un outil grand public comme Facebook permet il de publier sur sa timeline des contenus et alertes provenant d’outils tiers ? Une éternité. Et comment faisait on avant de recevoir des alertes dans son réseau social grand public ou d’entreprise ? On les recevait dans son mail. Serions nous en train de nous extasier et de sortir tambours et trompettes lorsqu’après de longues années de réflexion et de travail et au prix de budgets R&D conséquents un éditeur majeur reinvente l’alerting et introduit une innovation majeure : envoyer l’alerte dans un activity stream au lieu de l’email.

Non. Sérieusement ? Je veux bien pour ceux qui ont ouvert la voie en 2009 ou 2010. Mais en 2013 ? Autant je trouve que les deux premières voies sont prometteuses car permettant de travailler, agir et collaborer dans un contexte unique autant la troisième me semble méconnaitre une  dimension fondamentale du besoin : l’utilisateur final qui doit pouvoir travailler conjointement en mode « métier » et « social » dans un seul contexte, une seule et même interface. Ce qui conditionne à la fois la facilité d’adoption, donne une meilleure expérience utilisateur et rend la proposition de valeur en terme de gains de temps et de productivité plus évidente et lisible.

Ecouter et se positionner sur les tendances fortes c’est bien. Mais les prendre au pied de la lettre sans visiblement se mettre une seule seconde à la place de l’utilisateur final, n’avoir qu’une vision technique de la chose sans penser à la valeur que la technologie doit générer au final est quand même bien dommage et regrettable. Depuis le temps je pensais que le message avait été compris dans les R&D.

L’intégration des outils métiers et du social peut se faire à trois niveau :

- le simple « alerting » : en 2013 c’est se moquer du monde.

- alerting avec partage d’information riche : c’est beaucoup mieux

- rendre l’outil métier actionable depuis le réseau social : c’est la seule approche digne de ce nom et celle qui doit prévaloir à l’avenir

 
  • http://twitter.com/garniera garniera

    Je suis totalement en phase avec ton post. Et ravi d’avoir été selon ton propre terme un hérétique sur la question des processus qui maintenant est « logique ».
    Tu as bien raison de ne pas t’ébahir devant ce que tu appelles Alerting… je ne sais pas à qui tu fais allusion ?… ///

    Je vois en revanche une autre approche que les deux (solides en effet) que tu présentes… et qui propose une alternative et lève des limites aux deux modèles.

    Pour un besoin métier, ou le social se fait sentir, car le « hors process » est important, car le groupe est structurant, car on ne peut pas tout modéliser, il s’agit de penser entièrement une nouvelle application sociale, qui agrège les données de plusieurs applications métiers (hétérogènes), pour former de nouveaux objets Metiers et Social.
    Impossible alors de rajouter du Social sur une application (logique SalesForce), car on est en présence de plusieurs applications … parfois de technos très variées… ni d’actionner les objets métiers depuis le Social (IBM) car on joue sur les agrégats complexes et qui se forment dans le temps… et donc pas actionnables dans le Wall comme çà (à moins de mettre en branle la machine développement…).
    Ce qui est actionnable dans le Wall, ce sont des objets intérmédiaires du process Social qui peuvent donner in-fine en effet à une boucle retour mais pas immédiatement.

    On est bien obligé alors de créer de nouvelles applications complètes (à dominante sociale certe mais pas que) dont la vocation est de méler les deux dimensions.
    Cela permet quand même – et la dessus je te rejoins vraiment – d’actionner en retour le progiciel métier mais pas « directement », par l’intermédiaire d’une couche « MidleWare Sociale/Métier ». Ca peut paraitre théorique comme çà, mais si on veut vraiment tirer le jus du lien Social/Métier, il faut passer par cette abstraction, car qui dit social dit justement des processus collectifs, qui prennent du temps, et sont plus complexes que les objets gérés par les applications métiers classiques.

    Tu l’auras compris, c’est l’approche de Jamespot. Avec notre modèle de donnée et d’applications qui aggrègent métier et social pour donner à l’utilisateur une nouvelle interface de travail autant social que métier.
    Est ce digne? je ne sais pas… je ne travaille pas pour la dignité. Mais ce que je vois, c’est que cela répond à des besoins très identifiés aujourd’hui.