Je reviendrai plus tard, certainement en début de semaine prochaine, sur mes conclusions “à froid” sur ce Lotusphere 2011. En attendant voici une petite réflexion sur la mise en place d’un projet d’entreprise “social business” au regard de ce qui a été dit ces derniers jours.
Comme je peux l’expérimenter chaque jour, un tel projet est d’abord un projet d’entreprise, nécessite une vision managériale, organisationnelle et est, in fine, supporté par des outils permettant de travailler autrement. L’outil, dans ce contexte, peut être un catalyseur lorsque les choses sont bien pensées et soutenues à haut niveau mais ne déclenche rien de lui même. Il peut, par contre, devenir un inhibiteur lorsqu’il crée des silos applicatifs ou des silos d’usages qui ajoutent de la complexité à un existant déjà peu adapté aux réels besoins des utilisateurs.
Dans ce contexte la composante “sociale” du système d’information doit être une couche de services partagés davantage qu’un ou plusieurs outils comportant les fonctionnalités permettant ces usages sociaux. Je retrouve totalement mon analyse dans le “social business framework” où l’on se rend bien compte que la vision s’organise autour du flux d’activité, lequel est une sorte de hub collaboratif permettant le traitement des informations ainsi que l’action dans un contexte de travail unifié (comprenez, sans quitter sa fenêtre, sans changer d’outil). Cela nécessite de créer du lien entre un grand nombre d’applications dites “sociales” mais également métier (SAP, Cognos) sans oublier l’email (on peut dans ce contexte gérer ses mails dans son flux version “vulcan” même si on travaille, par exemple, avec Exchange) ou encore Sharepoint.
On voit bien là tout les éléments qui, selon moi, permettent de travailler sur le sens et l’alignement des nouveaux modes de travail et des outils qui les supportent plutôt que sur l’adoption que beaucoup confondent avec exhortation. Oui mais voilà…ça n’est pas si simple.
Il est peu envisageable qu’un projet démarrant “localement” sur un petit périmètre à l’initiative d’une personne ou d’une petite équipe ait les moyens de travailler à ce niveau, se privant ainsi des leviers essentiels qui font la différence entre bulle sociale qui fait peu de sens et est vécue comme une contrainte par l’utilisateur à un vrai outil de productivité globale. Cela ne veut pas dire qu’il ne faille pas procéder ainsi, parfois pour “découvrir”, mais dans l’optique du long terme il est essentiel d’avoir une vision globale du cycle de vie de l’information dans l’entreprise.
Cycle de vie de l’information ? Une fois tous ces outils connectés l’information n’est plus une donnée figée dans un réceptacle : elle vit, passe de collaborateurs en collaborateurs, est travaillée, améliorée, “actionnée” et concoure à améliorer la performance tout en optimisant les efforts et l’attention des collaborateurs. Mais si informations et échanges ne doivent pas subir de rupture de flux, il est essentiel d’avoir une vision globale des circuits à emprunter. Bien sur, au regard de ce j’écris plus haut, vous me répondrez que “peu importe, puisque tout est connectable dans la vision quasi middleware qu’IBM a de la couche sociale”. Soit, mais encore faut il le prévoir et en avoir conscience. Cela ne se fera pas en un jour mais si on n’y pense pas au début il y a peu de chances que l’on remette cette partie du travail aux calendes grecques…et qu’on s’en préoccupe trop tard alors que faute d’avoir atteint sa masse et sa vitesse critique le projet original n’aura pas réussi à décoller. Et nous savons tous qu’en la matière, si l’entreprise peut expérimenter autant qu’elle veut, on ne dispose souvent que d’un fusil à un coup pour mobiliser le collaborateur et lui donner la preuve des bénéfices qu’il a à tirer du changement.
Conclusion : la nécessité d’avoir une approche très “métier” et “terrain” des business cases ne dispense donc pas d’un schéma directeur global. Un concept qui n’a rien de surprenant dès lors qu’on parle de projets globaux mais qui émerge juste dans le domaine de l’entreprise 2.0 (ou du social business) où on a longtemps voulu se convaincre que tout devait se faire en clic et fonctionner de suite. A partir du comment où l’on comprend que la composante “sociale” est un service partagé du SI on comprend qu’à ce niveau on est davantage dans le projet d’infrastructure que dans le simple déploiement de solution. Un mythe du “social media” s’effondre peu à peu mais finalement ça n’est que logique : on n’a jamais vu de projet de transformation majeur se passer sans efforts ni vision globale. Celle-ci ne fera pas exception à la règle.
Dès que le mot intégration fait on apparition, les habituelles peurs resurgissent, et souvent à juste titre. Long, compliqué, couteux. C’est à cela qu’est sensé palier le “Social Business Toolkit“, qui est en quelque sorte le ciment qui maintiendra l’ensemble en place et facilitera les échanges d’informations entre les plateformes. C’est un immense pari : cette vision de middleware social au demeurant très pertinente, a besoin que ce Toolkit permette de faire très “simplement” des choses qui, auparavant, demandaient énormément de temps et d’énergie.
En attendant un conclusion s’impose. Si cette vision du “social software middleware” a énormément du sens en termes de cohérence, elle demande un travail de structuration en amont auquel on n’était pas habitué sur ce type de projet. A coté de la dimension “usages” et “business case”, un travail d’architecture SI sera indispensable. Et, bien sur, les deux devront avancer ensemble de manière cohérente.
La co-construction du SI et des usages qu’il supporte va devoir devenir une réalité.
Tags: intégration, Lotusphere 2011, ls11, project vulcan, SI, social business, social business framework, social business toolkit
[...] Ce billet était mentionné sur Twitter par Bertrand Duperrin et Nicolas Kleiber, olivier roberget. olivier roberget a dit: Empower People – Votre projet “social business” a besoin d’un architecte: http://bit.ly/hEEAsf [...]