Intéressante remarque chez Library Clips (décidément une bonne ressource) :

Think about it, a couple of us are interested in a topic or have a task to do…we create a group space in under a minute, and start participating.

The minute people need permissions, is a minute too long; they don’t bother and will use email. And if the design is not user-centric, they may eventually give up leaving a ghost town for email.

 A rapprocher des remarques sur "faire adhérer" ou "how to drive adoption"…

C’est ici, est c’est Anil Dash qui le dit : Google Wave est trop compliqué pour réussir (je résume…).

Trois séries d’arguments:

1. Techniques : le déploiement de protocoles compliqués (XMPP?),
2. Opérationnels : adoption progressive v. révolution (Wave est une révolution), en particulier pour les informaticiens (la notation sur le "week end project" est intéressante),
3. Socio-techniques : les outils existant sont suffisamment perfectibles pour rester attractifs (exemple de ce qu’il appelle PushButton Technologies).

[ET de toutes façons, je veux ce truc dès qu’il est disponible!].

En lisant une Nième matrice de comparaison Management 1.0 v. Management 2.0, une pensée me traverse:

C’est bien la fin du Need to Know; on est dans le "Need to Let Know".

La question, l’urgence présente face à tout ce qui nous passe sous les yeux, c’est "A qui ça peut servir? A qui dois-je faire savoir? A qui ça pourrait manquer si je ne le fais pas savoir?".

Un de mes clients me dit: "Dans notre process de Root Cause Analysis (en cas d’incident), nous avons ajouté une question systématique : "Qui n’a pas été prévenu? Avec qui n’a-t-on pas communiqué? A qui aurait-on dû parler?" A chaque fois on découvre des choses et on améliore nos manières de faire".

Un autre client disait "Je suis autant intéressé à la réussite de mes partenaires qu’eux-mêmes; je fais tout ce que je peux pour aider mes sous-traitants".

L’ardente obligation de faire savoir…

Je m’aperçois en re-triturant mon tableau synoptique autour du KM qu’il faut distinguer deux choses :

1. Le Knowledge Management Lifecycle (KML) : le Knowledge Management a un cycle de vie, observable dans la pratique en comparant (par exemple) le degré de maturité de différentes entreprises dans le domaine du KM; Le "KML" décrit les étapes de la maturation progressive d’une organisation dans la prise en compte et la gestion raisonnée des savoirs et des connaissances critiques à ses activités présentes et futures; Le KML inclut –dans ses phases tardives–
2. Le Knowledge Lifecycle Management (KLM, évoqué ici récemment) : le Knowledge lui-même a un cycle de vie observable au long du temps (par exemple au cours d’une démarche Kaizen); Le "KLM" décrit et exécute les opérations de gestion méthodique de ces savoirs et ces connaissances proprement dits, ainsi que les outils et techniques qui permettent cette gestion sur le moyen terme (en particulier : explicitation et recombinaison au sens de Nonaka et Takeuchi, opérations de veille technologique, surveillance et protection de l’IP, etc.).

Via Creative generalist (comme souvent) un document original et passionnant : les politiques RH de la société Netflix, racontées sans fard ni langue de bois, avec un système d’hypothèses clairement articulées… c’est très très séduisant, et bien des "principes" énoncés sont valides même dans un autre écosystème (j’adore les slides sur les congés :-) 63-68: je cite : "Netflix Vacation Policy and Tracking : there is no Vacation Policy or Tracking" c’est sérieusement argumenté) –AMHA vous pouvez aller vite sur les premiers slides, voyez 38-55 et la suite… presque tout serait à citer!

Ils arrivent en 128 slides –c’est sec comme un coup de trique– à énoncer :

• leur vision,
• leurs valeurs,
• leur modèle de management,
• des principes d’action au quotidien,
• incluant des critères de décision…