Résumé : si les collaborateurs rechignent à  utiliser la multitude d’outils, au demeurant utiles, mis à  leur disposition c’est parce qu’on leur demande de faire l’effort d’articuler différentes logiques de travail, formes d’information, et combler les trous entre les silos applicatifs. Non seulement ils n’ont pas tous la capacité de comprendre cette articulation, d’avoir une vision globale des outils et de leurs usages, mais ils n’ont, de plus, pas le temps de jongler entre les outils et servir de passerelle entre ce qui se passe dans chacun. On a longtemps considéré que ce rôle de middleware incombait aux collaborateurs. On ne fera pas l’économie d’une intégration poussée des différents outils pour substituer un investissement technologique « scalable » à  du temps humain qui ne l’est pas. Et contrairement à  ce qu’on a pu croire, cela concerne également le « social software » d’entreprise.

Le moins qu’on puisse dire est qu’on ne rechigne pas à  l’effort pour rendre le collaborateur plus productif et lui simplifier la vie même si, bizarrement, ce dernier n’a pas l’air d’apprécier les efforts faits pour lui à  leur juste valeur. Pire, il rechigne à  utiliser tous ces outils sur lesquels on a pourtant lourdement investi dans le but de l’aider à  être efficace en lui simplifiant la vie. On a, un temps, cru qu’il en irait tout autrement avec ce qu’on fait rentrer dans la catégorie de l’enterprise social software car il s’agit d’outils qu’il connait et apprécie dans sa sphère privée, simples, suffisamment flexibles pour qu’ils s’adaptent à  ses besoins plutôt que le contraindre à  un mode de fonctionnement…Mais au final on se retrouve dans la même situation : une gamme incroyable d’outils pour faire face à  tous les besoins quotidiens et finalement une utilisation relativement limitée.

Mettons nous à  la place du collaborateur. Devant lui : un client mail, un portail, un outil de gestion documentaire, un ou deux outils métier, un réseau social d’entreprise, une messagerie instantanée… De quoi à  la fois tout faire et trouver les solutions à  tous ses besoins au regard de l’information et des personnes accessibles. Et des canaux pour tous les modes d’échange : structuré, destructuré, synchrone, asynchrone, au sein d’un groupe restreint orienté projet, de communautés ouvertes orientées « sujet »…

La vérité est qu’on a fait le pari que le collaborateur savait intuitivement articuler des logiques et des outils, servir de passeur d’information.

– articuler des logiques : travailler dans des outils métier et aller chercher les réponses lui permettant de prendre des décisions dans un réseau social par exemple.

– articuler des des outils : passer d’un CRM à  un réseau social, puis à  la GED, envoyer un mail, revenir au CRM pour retourner enfin chercher quelque chose sur le portail. Reconstituer le profil d’une personne en aggrégeant les informations contenues dans l’annuaire, puis ses contributions sur un réseau social, sa contribution à  tel wiki d’entreprise ou programme d’innovation pour savoir s’il est bien la personne à  contacter alors qu’il ne s’agit que d’une seule personne.

– passer l’information : une discussion ici permet de générer une information là , une information trouvée là  sert de base à  une discussion se passant ailleurs. Pour cela il faut faire passer d’un outil à  un autre des informations. Un tableau venant d’un outil métier à  partager dans un espace de travail, une discussion dans un groupe ou communauté quelconque à  lier à  une action dans le dit outil métier. Au mieux on fait des copier / coller, au pire des copies d’écran…et au final on s’épuise et on ne fait plus rien.

Personne ne devrait avoir à  penser où retrouver des sources d’information liées à  une problématique métier : elles devraient lui être suggérées sur le même écran. « Vous pourriez visiter telle ou telle communauté en rapport avec ce produit, ce secteur d’activité et contacter untel en raison de son expérience sur le sujet). Un commercial ne devrait pas partir à  la pêche aux expertises et retours d’expérience pour répondre à  son client : elles devraient venir à  lui directement dans son CRM.

Personne ne devrait avoir à  jouer le passeur d’information ou le convertisseur d’information : les outils doivent être à  même de se les échanger entre eux en un clic où, a minima, faire le lien entre un objet et les conversations / échanges lui étant lié.

Très souvent la « donnée business » cause l’échange et l’échange enrichit la manière dont on prend des décision ou agit au regard de cette donnée. Il est donc indispensable que le passage de l’un à  l’autre soit naturel, que les composantes formelles et informelles du travail soient liées dans les outils si on veut qu’elles le soient dans les usages.

Bien sur cela va demander un certain travail de développement, d’intégration afin de développer cette couche logicielle intermédiaire et cela va avoir un coût. Maintenant il s’agit de savoir ce que l’on veut.

Cette articulation, ce travail de middleware sera, au choix, supporté par une couche technologique ou par le collaborateur. Dans le premier cas cela demande un effort en amont mais permet ensuite de fournir un environnement de travail cohérent et unifié qui enlèvera nombre de barrières au développement d’usages nouveaux et plus productifs. Dans le second on fait le pari que chacun est capable d’articuler naturellement différentes logiques de travail et les outils qui vont avec. Cela doit être vrai pour moins de 10% d’entre nous. On fait également le pari de substituer à  un investissement informatique scalable du temps humain qui lui ne l’est pas. Car si le temps gagné grâce à  une utilisation des outils a pour prix un temps supérieur passé à  jongler avec et les utiliser on ne peut en vouloir au collaborateur de faire le choix….de la productivité.

En somme le collaborateur n’a que rarement les compétences pour jouer le rôle de middleware et encore moins le temps. Et si on ne lui substitue pas une composante technologique il y a fort a parier qu’il continue à  refuser les améliorations qu’on lui propose.

Au fait, cela signe-t-il la fin du mythe du « social software plug and play », à  utiliser sans intégration ? Le retour des approches « lourdes » propres aux « legacies » ? Certainement dans une certaine mesure. La composante sociale doit être une couche partagée par l’ensemble du SI, ce qui ne se fera pas sans un minimum de plomberie. Et avec les éditeurs qui l’auront compris. Car ça n’est pas au collaborateur de jouer le rôle de plombier du SI mais aux DSI de mettre en place les tuyaux donc aux éditeurs de prévoir la chose en amont pour que cette mission soit la plus simple possible.

Gardons une chose en tête : tout système d’information qui met une solution à  plus d’un clic du problème perd un grand nombre de ses utilisateurs à  chaque clic supplémentaire.

 
  • patrick chabannes

    Vision réaliste des défait actuels de SI métier. Il n’est point besoin de la DG pour que le DSI et l’éditeur comprennent que l’informatique doit pousser les informations vers l’utilisateur. Les métiers devront se faire plus exigeant. Il n’y a pas de rayons. Ils furent à  l’origine de toutes les applications les concernant.
    J’adore votre terme du collaborateur middleware. je crains de me voir l’utiliser…