Depuis quelques jours, nous échangeons, avec Pierre, à
propos des Réseaux Sociaux d’Entreprise, ce qui m’a amené à proposer un cahier
des charges pour ce RSE. Cette après-midi, il me répondait par le tweet
illustrant ce billet (et le précédent) : « il
faut regarder les usages par les offres, et ne plus étudier la demande, les
besoins. » Ce qui revient à dire qu’il ne faut pas faire de cahier
des charges pour le RSE mais regarder ce qui existe dans le marché.
Ca me met dans une fureur noire au point que j’envisage de
passer la soirée au bistro (mais il y a un gros orage qui m’empêche de quitter
le bureau) : le cahier
des charges reste la base du métier. C’est, d’une part, ce qui va te
permettre de consulter les « acteurs » pour qu’il puisse te répondre
et te présenter leurs produits, et, d’autre part, ce qui va permettre de
communiquer entre les acteurs d’un projet informatique pour se répartir le
travail et définir ce qu’il faut faire.
Il existe des offres de RSE mais je suis persuadé qu’aucune
ne correspond à ce que j’ai décrit dans mon cahier des charges. Les
magnifiques applications que vont nous proposer les éditeurs vont contenir :
-
des « Wiki »,
-
des blogs,
-
des systèmes d’échange instantané, ….
Je ne vais pas nier l’intérêt de ces machins.
Par exemple, le Wiki est bien sûr utile mais n’est utilisable
que par un type un peu geek et ne peut en aucun cas être utilisé pour gérer de
la documentation qui serait amenée à quitter l’enceinte des utilisateurs du
Wiki (par exemple le sous-traitant d’un fournisseur, les services marketing et juridiques,…).
Comme je le dis souvent en donnant des conseils de blogage : le texte doit
être travaillé dans un traitement de texte, c’est fait pour ça…
Concrètement, ces outils peuvent être utilisés par les
équipes informatiques mais leur utilisation sera beaucoup plus problématique
par la hiérarchie et par les équipes « métiers » de l’entreprise,
voire des domaines très loin de l’informatique comme le commercial, le
juridique, le marketing, …
Les RSE qui existent ont été conçus sur la base des
applications et des besoins potentiels des utilisateurs, pas du tout sur la
capacité des utilisateurs à pouvoir simplement l’utiliser, voir à l’utiliser
tout court.
Un exemple. Tiens ! Je fais un appel d’offre pour
acheter un truc. Je vais l’envoyer pour validation au service des achats. Si je
le fais avec le système officiel de la boite de gestion de la documentation,
ils ne sauront probablement pas l’utiliser puisque le service des achats utilise
lui-même sa propre application qui permettra de gérer les achats de bout en
bout. Pire ! Il pourrait me demande de créer moi-même une entrée dans cet
Intranet que je ne maîtrise pas. Finalement, ça se traduit par un coup de fil
entre les chefs pour démerder la situation puis l’envoi du document par mail.
Ce dont on a besoin est un truc dont on aura l’usage
et il n’est pas sûr que les outils du marché de Réseau Social d’Entreprise
répondent à ce besoin. D’où l’intérêt de mon cahier des charges qui prend
en compte avant tout la prise en main par l’ensemble des utilisateurs
potentiels.
C’est un peu le principe de Lotus Notes, d’ailleurs (sauf
que je n’ai jamais vu une application autre que celles présentes par défaut
bien foutue, c’est un autre problème), mais qui a d’autres défauts… On a, à la
base, un système de messagerie et d’agenda partagé. Les applications viennent
se greffer par-dessus. Lotus Notes a d’autres défauts… mais est pourtant
utilisable par tous les employés de bureau du monde et une part très importante
des grandes entreprises l’utilise.
C’est le principe de mon cahier des charges. On a un truc
incontournable avec un accès à la messagerie et un accès à l’agenda, qui sert
de point d’entrée à l’Intranet. J’y rajoute une couche de réseau social pour
faire joli avec des cercles dont on trouvera bien l’usage. J’y ajoute aussi un
système d’échange de fichiers « autrement que par mail ».
Les applications viendront après. Elles pourront se reposer
sur le mail, l’agenda, les cercles (ou groupes d’usagers) et les fichiers (ou
documents) et sur l’ergonomie générale du produit (vous avez déjà été perdu
avec une application Facebook, vous ?).
Ne mettons pas les charrues avec les bœufs.
Notre conversation sur le RSE a commencé par la
démonstration que les RSE ne servaient à rien parce que les salariés de l’entreprise
n’en auraient pas l’usage.
Il faut donc soit ne rien faire soit définir un RSE dont
on aura l’usage.
Fureur noire, oh non, il ne faut pas ! Pas pour un RSE, l'orage peut être, une pluie diluvienne why not, mais pas un RSE ... qui ne sert à rien..
RépondreSupprimerIl me fallait un prétexte pour aller au bistro.
Supprimerah, ok, c'est un bon prétexte ! quelques bulles pour être plus créatif
RépondreSupprimerOuf.
Supprimer