Comment les “quick wins” peuvent induire en erreur

18 October 2011 By 1 Comment

Résumé : la plupart des projets visant à changer les modes de travail ou introduire de nouveaux outils commence par une phase où l’on va rechercher des “quick wins’, démonstration à périmètre restreint et investissement quasi nul que la promesse est tenable.  Bien qu’il s’agisse d’une attente logique et sage, il faut bien se méfier de donner trop d’importance à ces quick wins ou à leur absence. Le contexte spécifique de l’expérimentation fait que rien ne permet d’extrapoler à l’ensemble de l’organisation, lorsqu’il ne s’agira plus d’un projet “sous surveillance” avec ce que cela implique pour ses participants. Se donner des objectifs en termes de compréhension de la nouveauté plutôt que démonstration de la promesse est plus enrichissant et moins trompeur.

 

C’est le passage obligé de tout projet digne de ce nom : le “quick win’. Autrement dit le fait d’arriver rapidement à un résultat tangible, même modeste, afin de prouver que le choix est bon, la promesse tenable et qu’on peut passer à la vitesse supérieure. Le “quick win” est bien sur recherché dès les premiers temps du déploiement mais également souvent en mode pilote pour savoir si on va plus loin où si on arrête.

A priori c’est une démarche saine et nécessaire : pourquoi investir dans un projet d’envergure sans trop savoir s’il est en mesure de tenir sa promesse. Mais la pratique n’est pas sans dangers.

Tout d’abord parce que le “quick win” doit souvent avoir lieu sur un périmètre restreint, ce qui ne facilite pas les choses sur des dispositifs ayant besoin d’une masse critique. Pour pallier à ce problème, on choisit les “bons” participants à l’expérimentation. Ce qui pose deux problèmes. Le premier est que si on choisit vraiment les “bons” on biaise le projet car on ne démontre pas que le salarié lambda peut rentrer dans la démarche. Le second est que souvent l’entreprise est incapable de trouver les bons et prend “ceux qui devraient” et “ceux dont on aimerait qu’ils..” mais jamais “ceux qui s’intéressent et aimeraient participer à”.

Ensuite parce que le “quick win” doit s’obtenir “avec les moyens actuels”, entendons sans conduite du changement ou toute autre forme d’effort. Ce qui n’est pas sans entrainer des situations ubuesques. “Nous avons conscience de l’importance de la conduite du changement dans un tel projet mais ne mettrons ce dispositif en place qu’en cas de succès du quick win”. Pas gagné…

Vient ensuite le contexte. On a affaire à des personnes qui savent qu’elles sont observées, qu’on attend quelque chose d’elles. Et bien, devinez quoi, le plus souvent si l’objectif est clair et qu’elles sont bient “brieffées”, elles produiront le fameux quick win en moins de temps qu’il ne faut pour ne le dire. C’est ce qu’on appelle l‘effet Hawthorne. Mais lorsque, suite à ce fameux quick win, on décidera de passer à la vitesse supérieure, la banalisation de l’expérience fera que ces mêmes personnes se désinvestiront aussi vite.

Ajoutons que rien n’est plus facile que de “coacher” les participants de manière tellement serrée que le scénario rêvé se réalisera comme par enchantement. Faciliter les choses est bien en termes d’exemplarité (tout le monde croit que c’est “vraiment” arrivé) mais ne prouve ni n’apprend rien à personne.

Ce sont autant de raisons qui montrent que :

- l’absence de quick win ne veut pas dire que l’idée était mauvaise

- l’existence d’un quick win montre simplement que les choses étaient possibles avec des personnes données, dans un contexte précis. En aucun cas qu’il est possible d’extrapoler à l’ensemble de l’entreprise.

Faut il, dès lors, abandonner le quick win ? En aucun cas car il est bon de tester, de valider certaines choses avant de se lancer. Par contre il est dangereux d’en faire la condition sine qua non de la poursuite ou de l’arrêt du projet. Il faut davantage le prendre comme une phase 0 où l’on apprend et dont on tire toutes les conclusions en connaissance du contexte dans lequel elle a eu lieu. Dans ce sens des objectifs en termes d’apprentissage de l’organisation face à une nouveauté mal connue sont plus pertinents que des objectifs liés à la démonstration d’une promesse beaucoup trop tributaire de son contexte.

 

Filed Under: Entreprise 2.0, Intranets & Digital Workplace, Management & RH Tagged With: , , , , ,

Et si on en finissait avec les organisations fantômes improductives ?

30 August 2011 By 6 Comments

Résumé : l’entreprise va devoir faire évoluer son modèle organisationnel et managérial. Projets, pilotes, initiatives diverses pullulent afin d’expérimenter, apprendre, comprendre. Mais quel est le temps raisonnable de la période de ce qu’on nomme souvent les “bacs à sable” ? On a souvent coutume de dire que cela doit durer le temps que cela doit durer mais il y a un risque réel qui grandit avec le temps. Nombre de projets ne font ni plus moins que créer des organisations fantômes au sein de l’entreprise, organisations qui sont parfois en compétitions les unes avec les autres et quasi systématiquement avec le fonctionnement “officiel” de l’entreprise. Au final personne ne gagne dans ce jeu à somme nulle lorsqu’il dure trop longtemps : l’entreprise perd en performance immédiate, le projet peine à réaliser sa promesse et le collaborateur se démotive. Il est essentiel qu’à un moment donné l’entreprise se réaligne sur les projets qu’elle a enfanté sous peine de tout perdre.

S’il y a un consensus sur le fait que nos organisations ne sont plus des modèles d’efficacités et que les choses ne s’améliorent pas avec le temps, cela ne va guère plus loin. A la limite on peut dire qu’il y a une relative convergence quant au modèle futur mais entre les différentes approches et le courage nécessaire pour en tirer toutes les conclusions, on est encore dans une phase un peu nébuleuse. Quant à savoir quel chemin prendre pour y parvenir, là c’est le grand Barnum. Par le haut, par le bas, par les deux cotés, de manière dirigiste ou facultative, en mode évolutionnaire ou révolutionnaire…. Il parait que tous les chemins mènent à Rome, espérons que c’est vrai. Ce qui quelque part semble logique : sur des projets qui font la part belle à l’Homme (à la fois comme objet, levier et sujet) on ne peut négliger le passé, la culture etc…

Si on résume, l’organisation en mode “push” a vécu. Vive le “pull”. Conséquence, l’essentiel de ce que l’on nomme management est de compliquer la vie des salariés (ça n’est pas de moi mais de Peter Drucker…et j’y souscrit en grande partie). Cela amène au besoin de renverser la pyramide, et de le faire de manière intelligente et productive et me rappelle une anecdote tirée de l’expérience de Vineet Nayar. Au début il a posé les premières briques de cette organisation conçue pour servir ceux qui créent effectivement de la valeur avant de se rendre compte des limites de sa démarche. Tout ce qu’il construisait s’appliquait et reposait sur l’existant, sur des systèmes et des processus conçus pour être descendants. D’où une démarche visant non plus à poser un cautère sur une jambe de bois mais à créer, pas à pas, un système cohérent par rapport à ses objectifs.

Jetons maintenant un œil sur les démarches de type entreprise 2.0 ou social business. Dans combien de cas se sont elles accompagnées d’un travail de reconfiguration de certains process, d’une réflexion sur la traçabilité de la valeur, sur les modalités d’évaluation des uns des autres ? Bien sur, nous sommes devant un phénomène jeune et “émergent” comme on dit. Mais comme je l’ai encore entendu la semaine dernière de deux personnes que l’on peut considérer comme des convaincus, des “advocates”, des ambassadeurs des projets menés dans leurs entreprises. “A force d’être jeune ça commence à devenir vieux”. “Ok pour que ce soit un peu chaotique au début…mais là ça fait 5 ans qu’on expérimente dans tous les sens, qu’un projet succède à un autre mais ‘au dessus’ ils ont toujours pas compris qu’il fallait siffler la fin de la récré et mettre les choses d’équerre”. “Franchement, j’en ai marre de me battre. Vu a quoi ça sert je pense avoir pris assez de coups comme ça”.

De quoi parlaient ils ? Du fait que ces projets génèrent des modes de fonctionnement et des structures qui vont, selon les cas, contre l’organisation officielle, en compétition avec elle, voire des projets internes qui sont en compétition les uns avec les autres. [Read more...]

Filed Under: Entreprise 2.0, Management & RH Tagged With: , , , , , , , , , ,

Mettre en place un pilote n’est pas qu’une question de dimensionnement

18 May 2010 By 2 Comments

Andrew McAfee à récemment fait resurgir au premier plan la question déjà soulevée par Michael Idinopulos il y a de cela plusieurs mois : le concept de projet “pilote”  est il adapté à l’entreprise 2.0 ou faut il s’en débarrasser. Premiers (excellents) éléments de réponse à trouver chez Emanuele Quintarelli.

En fait il existe un présupposé derrière cette question qui part de certaines hypothèses qui ne se vérifient pas systématiquement :

1°) Le pilote s’applique à des activités “over the flow”

2°) La seule chose qui caractérise un pilote est son dimensionnement limité en termes de participants.

Dans cette hypothèse où la nécessité d’une masse critique est…critique, la limitation du nombre de participants est effectivement une hérésie qui équivaut à se tirer une balle dans le pied dès le démarrage du projet. Quitte à limiter quelque chose, autant limiter la durée que la taille, ce qu’à fait intelligemment CSC par exemple.

Oui mais voilà, réduire la question du pilote à une question de dimensionnement est peut être aller un peu vite en besogne.

1°) La question d’une phase préliminaire ?

Avant même d’aller plus loin dans la réflexion, il faut se poser la question de la nécessité d’une phase préliminaire avant que l’entreprise ne donne une dimension globale à son projet. Bien évidemment la réponse est oui : on ne plonge pas dans le grand bain sans avoir testé la température ni s’être rassuré en nageant dans une zone où on a pied.

L’essentiel n’est donc pas là. Il est davantage dans le contenu de cette phase. A commencer par ses objectifs.

2°) Quels objectifs ?

Je ne vais pas m’étendre sur le sujet puisque je l’ai déjà abordé il y a quelques temps. Il importe de savoir si cette phase vise à apprendre à apprivoiser une logique nouvelle qu’on implémentera de toute manière où elle sert à décider si l’on fera ou pas. L’enjeu n’est pas neutre : difficile d’impliquer les collaborateurs dans un projet qui peut s’arrêter du jour au lendemain et à la pérennité aléatoire.

3°) Quel nom ?

Aussi bizarre que cela puisse paraitre la manière dont on va appeler cette phase n’est pas neutre. Du coté des utilisateurs d’abord (pilote = rassurez vous on n’abandonnera pas…mais peut sembler un peut top/down et directif, expérimentation = vous êtes des cobaye et on ne promet ni ne garantit rien), mais également du coté de l’entreprise, certains “namings” permettant de décrocher plus facilement le label “projet d’entreprise” et le soutien effectif du top management.

Mais peut être certains ont il trouvé l’appellation magique qui concilie la chèvre et le choux, motive sans froisser ni décourager.

4°) Quelle expérience sociale ?

Et c’est peut être par cela qu’il faut commencer. Déployer logiques et outils dits “2.0″ dans l’entreprise n’est pas mettre en place quelque chose d’uniforme. Comme j’ai déjà pu le mentionner il y a le “social for communities” et le “social for teams”. En d’autres mots, que l’on essaie de réunir une population au départ indéfinie autour de grands thèmes où qu’on essaie d’optimiser le fonctionnement “organique” de l’entreprise (équipes – départements – services), on est dans les logiques qui, quoique complémentaires, sont belles et bien différentes. Je ne m’étendrai pas sur les différences de management et de leadership entre les deux, sur la différence entre conversations et intéractions, ce qui importe ici est que dans un cas il faut une masse critique, dans l’autre un travail plus profond sur l’alignement et l’intégration dans les pratiques quotidiennes. Bref, l’éternelle différence entre les approches in the flow et over the flow qui est, je le répête, beaucoup trop souvent passées sous silence et négligées par rapport à leur impact sur la nature d’un projet.

La “vérité” de l’entreprise fait que les deux logiques se doivent de cohabiter dans l’entreprise, donc dans une phase préliminaire. Par contre en fonction des objectifs que l’on se donnera (on peut “expérimenter” sur plusieurs expériences sociales à la fois), on saura que certaines sont par définition limitées en termes de participants et que d’autres ont dès le départ, besoin d’une masse critique.

Vous l’avez compris, plus qu’une question de dimensionnement ou de “pilot or not pilot”, il s’agit de savoir ce que l’on cherche à valider, à apprendre…et le reste en découle quasi naturellement.

Filed Under: Entreprise 2.0 Tagged With: , , , , ,

Vous pilotez ou vous expérimentez ?

6 May 2010 By 1 Comment

Quand une entreprise fait ses premiers pas dans quelque chose de nouveau elle avance avec précautions et c’est logique. Même si on a une idée précise de ce qu’on va faire, il faut le tester sur une petite échelle afin de valider certains concepts, confronter le plan à la réalité. Je ne parle même pas de l’hypothèse où on essaie quelque chose sans trop savoir à quoi cela sert ni s’il y aura un bénéfice au bout.

Le principe s’applique à un nombre infini de choses et l’entreprise 2.0 ne fait pas exception à la règle. C’est sur ce sujet que vont porter plus spécifiquement mes réflexions même si on peut sans grand risque le généraliser à de nombreux autre domaines.

Je ne vais pas pas refaire la discussion qui a déjà eu lieu sur le sujet à la fin de l’été dernier et qui revenait à se demander si ces phases préalables, quel que soit le nom qu’on leur donne, avait du sens. En effet qui dit périmètre restreint sur un sujet ou la masse critique est souvent clé dit, par définition, possible manque de pertinence.

Concrètement la question qui se pose est de savoir :

1°) Ce qu’on fait

2°) Comment on l’appelle et le présente.

Et nous allons voir que c’est loin d’être neutre.

[Read more...]

Filed Under: Entreprise 2.0, Management & RH Tagged With: , , , , , ,

Mais pourquoi n’ai-je pas utilisé cette satanée application plus tôt ?

27 November 2009 By 4 Comments

Il y a quelques semaines de cela j’étais en réunion en train de prendre des notes. Un coup d’œil sur l’écran d’une collègue pique ma curiosité et je lui demande : “tiens…c’est quoi l’application que tu utilises”. Et elle de me parler de cette application fantastique découverte quelques semaines plus tôt. Quant à moi je n’ai qu’à m’en prendre à moi même : ça ne fait pas des semaines mais des mois, beaucoup de mois qu’elle est installée sur mon ordinateur. J’avais même eu accès à la “bêta”, j’avais rapidement regardé et j’étais passé à autre chose. Non parce que l’application en question était bonne ou mauvaise mais parce que je n’avais voulu prendre le temps de me poser certaines questions. Et c’est là que ça peut devenir intéressant.

Comme tout le monde j’ai ma petite routine pour le traitement de l’information. Il y a les notes que je prend, il y a ce que je vois sur le web. Ensuite vient une phase de “mise en attente” et de traitement qui m’amène à lire et effacer, garder au cas où, bookmarker, ou entreprendre quelque chose. Cette même routine s’applique aussi bien pour mon activité professionnelle que pour ma veille personnelle et l’alimentation de ce blog (pas difficile il s’agit des mêmes sujets). Et bien sur j’ai organisé ça par rapport aux applications utilisées : à chaque tâche son application et à moi de gérer l’évolution du statut et du traitement selon une routine bien précise : chaque information présente quelque part est à un stade précis.

Changer une seule des applications m’imposait donc de changer ma routine. Même si l’application est meilleure, ça ne compte pas. C’est inconscient et c’est comme ça. Ensuite, s’agissant d’un test, cela impliquait que je doublonne ou que j’éparpille des choses avant d’être sur de tout migrer ou de ne pas poursuivre l’expérience.  Vu que je n’avais pas de temps à perdre je me suis contenté de regarder les fonctions rapidement sans m’en servir en conditions de travail. Cela relevant plus du jeu que d’une utilisation appliquée à mes préoccupations personnelles, j’ai vu des fonctionnalités mais faute de les appliquer à une utilisation réelle et quotidienne je n’ai pu identifier les apports, les bénéfices. Un dernier point manquait enfin : je n’ai pas non plus voulu prendre le temps de réfléchir au périmètre d’un tel logiciel : pro/perso, note ou notes+autre chose, chevauchement avec d’autres choses déjà utilisées. Tout cela cumulé faisait que j’étais incapable de projeter l’utilisation de cette application nouvelle dans mon quotidien, de m’imaginer ce que cela pouvait donner au niveau de ma routine personnelle, de me “voir” dans ces conditions.

Voilà pourquoi j’ai failli rater le train “Evernote“.

Un cas finalement très simple. Imaginez ce que cela donne lorsqu’une personne doit conduire l’”expérimentation” d’une plateforme de logiciel social en entreprise, et la situation de ceux qui sont désignés volontaires d’office pour y participer. On ne parle pas d’une personne mais de 10, 100, 500, des personnes qui, qui plus est, ne sont pas aussi technophiles que moi et n’ont pas la latitude et le recul que je peux avoir dans le choix de mes outils. En plus il ne s’agit ici que d’une problématique individuelle, où la question du partage, de l’alignement des pratiques et de l’utilisation d’une même application par tout un groupe ne se pose pas. Un autre point à avoir en tête lorsqu’on construit son pilote entreprise 2.0 donc.

Filed Under: Logiciels et Outils, Web & Usages Tagged With: , , , , ,

10 questions auxquelles répondre pour réussir votre projet entreprise 2.0

10 November 2009 By 1 Comment

On a l’habitude de dire que pour réussir il y a des choses à faire. Mais à force de toujours privilégier l’action et de dédaigner la réflexion on risque de faire n’importe quoi et gâcher de belles opportunités. Pour réussir il faut aussi avoir des réponses. Des réponses qui permettent de passer d’une étape à l’autre. Des réponses qui permettent d’être sur qu’on ne se trompe pas de projet. Des réponses qu’il faudra donner à ses supérieurs pour prouver qu’on ne jette pas l’argent par les fenêtres et que l’initiative mérite son budget et un soutien actif.

A chaque phase du projet  il faut se demander si on a la réponse à quelques questions clé. Et faute de réponse il importe de lever le pied et de consacrer son énergie à la trouver avant de persévérer dans une une direction qui pourrait être fatale.

Si l’on considère qu’un projet comporte en gros 3 phases, l’exploration où on essaie de comprendre un phénomène au départ inconnu, le pilote où on valide ce qu’on a cru comprendre, et l’industrialisation qui est la généralisation à l’échelle de l’entreprise, voici 10 questions clé auxquelles vous devez avoir des réponses.

Il n’y a pas toujours de bonne ou de mauvaise réponse. Mais par contre il en faut une. Lorsque la réponse se limite à “oui” ou “non”, je vous laisse trouver de vous même quelle est la bonne réponse…et que signifie l’autre.

1°) A l’issue de la phase d’exploration

Qu’est ce que les outils que je compte utiliser font et ne font pas ? Ou plus exactement pour quoi sont ils conçus et pour que ne sont ils pas conçus ?

Ai-je une idée de la manière dont mon projet va impacter le travail quotidien des utilisateurs ? Puis-je visualiser la situation future, me projeter ? Et suis-je prêt à l’assumer ?

Puis-je  évaluer l’impact de mon projet sur la chaine de valeur, sur la création de valeur, sur l’efficacité au quotidien (au moins théoriquement) ?

2°) En phase pilote

Les contenus et informations partagés le sont il du fait des utilisateurs ou de personnes à qui on demande d’occuper le terrain ?

Ai-je formalisé, communiqué, les “outcomes” attendus ? Et vérifié qu’ils avaient du sens dans le quotidien des collaborateurs ?

Suis-je sur que les intervenants sur le projet (internes comme externes) ont pour objectif de faire délivrer ces “outcomes” ou de faire en sorte qu’il y ait simplement du bruit dans l’outil afin de mériter leur paie ? L’utilisation de l’outil est elle devenue la finalité du projet au détriment de tout objectif opérationel ?

Ai-je organisé la réutilisation de ces fameuses intéractions sociales et de leur produit au service du business (comment l’idée deviendra projet, comment le collaborateur pourra accéder et réutiliser le savoir et l’aide de ses pairs, comment on pourra mobiliser une ressource identifiée au gré de ces intéractions…)

Ai-je réfléchi à la notion de “routine sociale” avec les métiers, les managers, et commencé son implémentation ?

3°) En phase d’industrialisation

Ai-je des indicateurs concrêts permettant de mesurer l’apport de la logique “sociale” au business (longueur du cycle d’innovation, longueur du cycle de vente, chiffre d’affaire, nombre de bonnes pratiques capitalisées, réunions évitées, idées recueillies, longueur du cycle de décision, diminution du temps passé par les managers à faire de la mise en relation….)

Ai-je  des exemples de choses qui ne se serait pas produites sans le projet ? Et quel a été leur impact ?

Ca n’est bien sur pas exhaustif mais il est à peu près certain que l’incapacité de fournir une réponse à une de ces questions, voire parfois une mauvaise, risque de se payer au prix fort un jour ou l’autre alors que prendre le temps d’y penser au bon moment évitera des désagréments futurs.

Filed Under: Entreprise 2.0, Web & Usages Tagged With: , , , , , , ,

Faut il un pilote dans l’entreprise (2.0) ?

16 October 2009 By 4 Comments

Tout est parti de ce billet provocateur de Michael Idinopulos. Son message est relativement simple, clair, compréhensible. Partant du principe que l’entreprise 2.0 repose sur des intéractions en réseau, que les dites intéractions nécessitent une masse critique non seulement en raison de la Loi de Metcalf mais aussi parce que par définition on ne sait au départ de qui on aura besoin à un moment donné, il en conclut que dans une perspective entreprise 2.0 les habituels pilotes mis en place par les entreprises n’ont aucun sens et ne permettent pas de démontrer quoi que ce soit.

Une prise de position qui a entrainé nombre de réactions sans qu’aucune solution tranchée n’émerge vraiment (voir les réactions au post de Steven Walling ainsi que les résultats de son sondage). Au final il semble que bien qu’une phase d’apprentissage, de découverte, soit nécessaire, les avis diffèrent quant à ses modalités. Ou, dit autrement, tout le monde est à peu près d’accord mais on diverge sur les points de détail voire sur la manière dont on formule les choses.

Qu’est ce qu’un pilote ?

Qu’est ce qu’un pilote ? C’est un projet permettant de tester sans trop de risque et sur un périmètre restreint les points clé de quelque chose qu’on désire mettre en application de manière plus large dans le futur. Ou, plutôt, c’est la manière dont on a généralisé le contenu d’un pilote. Si, on se concentre sur l’objectif il s’agit d’apprendre à valider quelque chose de nouveau, apprendre à le maitriser, en appréhender les risques et les limites. Dans le contexte de beaucoup de choses qui se sont faites par le passé, la définition donnée un peu plus haut est totalement pertinente par rapport au but car, au final, la seule chose qui différencie le pilote du projet final est le dimensionnement, la scalabilité. Dans un système reposant sur la transaction il suffit de vérifier que le processus fonctionne pour 10 personnes, ensuite le faire fonctionner pour 100, 1000 ou 10 000 n’est qu’une question d’infrastructure.

Conversationnel ou transactionnel ? Deux logiques différentes.

Ce qui est nouveau dans le domaine de l’entreprise 2.0 en tant que projet informatique c’est sa dimension humaine, peu transactionnelle, peu prévisible et le fait qu’il repose sur un réseau d’individu. Autrement dit ça n’est pas parce que quelque fonctionne avec 10 personnes que ça fonctionnera avec 1 000. Mais surtout, cas le plus fréquemment rencontré : quelque chose qui ne fonctionne pas avec 10 ou 100 personnes peut parfaitement fonctionner avec 1 000 ou 10 000. Si internet n’avait que 1000 utilisateurs les réseaux sociaux tels qu’on les connait n’existeraient peut être pas, la probabilité pour chacun de trouver son réseau, son audience en phase avec ses problématiques ou envie devenant d’un seul coup très faible.

Il existe également un autre point qui est loin d’être anecdotique : on peut tester une application transactionnelle “à blanc”, en lui injectant des données et voyant ce qu’il en sort. Une application plus “conversationnelle” ne peut être ainsi mise en salle blanche, déconnectée de la réalité opérationnelle. Isolée des préoccupations quotidiennes de manière à ne rien impacter,  elle ne peut donner aucune preuve ni piste quant à son utilité et son efficacité future.

Le but du pilote s’applique donc à l’entreprise 2.0 (tout du moins à sa composante logicielle) mais ses modalités doivent certainement être revues pour rester cohérent avec le but poursuivi dans le contexte spécifique des applications 2.0, notamment ce qui concerne le dimensionnement et le positionnement par rapport aux besoins et objectifs quotidiens des collaborateurs.

Une bonne synthèse de ce que doit être un pilote 2.0 une fois ce contexte pris en compte peut être trouvée dans le commentaire de Claire Flanagan. Un commentaire qui prend d’autant plus de poids lorsqu’on voit les résultats du pilote actuellement mené par la dame.

Un pilote n’est pas un explorateur

Un pilote sert à valider, à affiner la compréhension qu’on a d’une problématique, et à se donner les outils nécessaires pour….piloter le projet une fois qu’il sera généralisé. Dans notre contexte il importe donc qu’il existe une masse critique d’utilisateurs et que le dit pilote ne soit pas confiné en salle blanche et isolé de la réalité du quotidien. En tout état de cause cela impose qu’on ait déjà une idée de ce dont quoi on parle, de ce à quoi ça va servir, des changements préalables au projet et de ceux qui risquent d’en découler.

Lorsqu’on confine un pilote à quelques personnes et qu’on le coupe du monde, c’est souvent qu’on ne sait pas trop ce qu’on va faire, ce que permettent ou non les outils, quel peut être leur apport et leur impact au quotidien, ce qu’ils permettent de changer et le changement préalable nécessaire. C’est une phase de découverte des outils et des concepts sans rien d’opérationnel qui, comme cela a été expliqué plus haut, ne peut rien permettre de prouver. Cela permet, au mieux, de comprendre si tant est qu’on arrive à appréhender l’étendue des possibles avec un périmètre si restreint. Mais dans ce cas il ne s’agit pas d’un pilote mais plutôt d’un explorateur qui a vocation à défricher le terrain. C’est une composante de la nécessaire et trop souvent oubliée (ou expédiée) phase de réflexion stratégique amont mais, au final, en aucun cas un pilote. Et lorsqu’on attend d’un “explorateur” la même chose que d’un pilote on est nécessairement déçu par le résultat final.

S’il importe donc de prendre en compte les spécificités du paradigme 2.0 dans la mise en place de pilotes, il ne faut pas non plus appeler pilote ce qui n’est qu’un élément de la phase d’exploration et de compréhension préalable à celui-ci, qui sert à défricher avant de lancer le pilote, qui permet de comprendre  pour éviter de mal entreprendre.

En attendant vous pouvez également lire ce qu’en pense Steward Mader.

Filed Under: Entreprise 2.0, Intranets & Digital Workplace, Logiciels et Outils, Web & Usages Tagged With: , , , , , , , , , ,