LEMM : quelques clarifications

J'ai reçu plusieurs commentaires très intéressants, par email ou sur le blog (merci Patrice). Je vais répondre sous forme de post pour pouvoir suivre une démarche structurée (et aussi parce que Blogger m'a perdu ma première réponse sous forme de commentaires, ce qui m'a hautement frustré).

(1) Email et Gestion de boite

Un des commentaires que j'ai reçu remarque que chacun utilise sa boite-aux-lettres de façon différente (avec des dossiers, etc.). Pour une personne qui conserve tous ses emails reçus, la notion de taille de boite « N » n'a pas beaucoup de sens. En effet, il faut considérer dans le post précédent N comme le nombre de messages actifs qui attendent un traitement. La plupart des gurus de l'efficacité recommandent d'utiliser une autre structure pour sauvegarder l'ensemble des emails reçus, mais ceci est un autre sujet. Celui qui m'intéresse est bien ce que Patrice Legoux appelle la « minimisation du stuff à faire ».

C'est d'autant plus important à préciser que la Loi de Little (N = l x T) , ne fonctionne avec T = temps de traitement que si N représente précisément la « nombre d'emails pour lesquels il reste quelque chose à faire ».

Comme on me l'a fait remarquer, ce qui rend la méthode de gestion de la boite importante n'est pas théorique mais pratique. En théorie, on pourrait balayer sa boite, classer et prioriser et gérer des files d'attentes multiples. Dans la pratique, il y a l'erreur humaine, qui augmente en fonction de la taille de la boite.

(2) JIT email, indépendance et couplage

Le lecteur aura remarqué que la pratique du JIT induit un couplage entre émetteur et destinataire. C'est une contrainte (assurément) qui réduit l'indépendance de chacun au sein d'un processus globale, ce qui peut ressembler à une régression. On touche à une des aspects contre-intuitifs du Lean. C'est pour cela que je n'imagine pas une seconde la pratique du JIT comme une vertu en soi, mais plutôt comme une déclinaison au courrier électronique de la pratique du Lean chez les knowledge workers.

Un exemple simple et illustratif est celui de la veille technologique. La pratique usuelle est que les « veilleurs » poussent leur information dès qu'elle est prête. Les destinataires s'en servent quand bon leur semble. La pratique Lean est au choix d'utiliser un serveur de documents pour que destinataire soit en mode « pull » et aille chercher l'information au bon moment, ou alors d'envoyer le rapport de veille par email « au bon moment ». Ce couplage impose que le veilleur connaisse le calendrier des besoins de ses lecteurs. C'est assurément contraignant, mais c'est aussi une source d'efficacité : plus les lecteurs s'expriment sur leur besoins, plus la veille est pertinente.

(3) email et autres canaux de communications

Je suis bien sur 100% d'accord avec Patrice Legoux lorsqu'il insiste sur le fait que le courrier électronique n'est qu'un outil parmi d'autres et qu'il faut considérer l'ensemble pour avoir une vue globale (en terme d'efficacité).

C'est même ce sur quoi je travaille depuis 4 ans sous le nom de démarche SIFOA (cf. les posts plus anciens de ce blog) : caractériser les différents canaux pour pouvoir comparer leur efficacité. C'est ce qui m'a permit de faire quelques comparaisons entre email, réunions, IM et téléphone.

Mais le fait de voir un système global n'empêche pas d'étudier les sous-systèmes ! C'est ce que je fais depuis 3 ans sur les réunions. Les réunions forment un canal de communication très complexe et on ne peut pas se restreindre à une seule vue globale de type SIFOA (à un moment, il faut se restreindre sur son champs d'investigation pour mieux analyser – qui trop embrasse mal étreint J). Je suis même allé plus loin en étudiant en détail les réseaux d'affiliation formés par les systèmes réunions. L'étude du réseau « email » est très intéressante en soi, indépendamment du couplage avec les autres réseaux de communication. Cela d'autant plus que c'est un réseau simple et explicite, qui a été bien étudié dans la littérature scientifique (cf. mon second livre pour quelques références). On sait de plus en plus de choses sur ce canal de communication, ce qui permet de confronter l'analyse à la réalité, ou de faire des simulations avec les « vrais » paramètres.

On peut faire le parallèle avec l'architecture organisationnelle (le titre de ce blog). Je ne prétends pas une seconde que l'analyse structurelle que je fais (cf. la décomposition de Bolman entre structure, politique, ressource humaine et symbolique) est une approche compréhensive du management ! La structure n'est qu'une petite partie du sujet … mais c'est une partie que je maitrise mieux que d'autres, et pour laquelle les méthodes scientifiques que je développe (ex : GTES) permettent d'obtenir des résultats. Ces résultats ne sont que des « insights » parmi d'autres, mais non moins intéressants.

(4) Mesurer l'impact du spell-out email ?

On m'a demandé s'il existait des études, au-delà de l'intuition systémique. Je n'en connais aucune, mais compte-tenu des informations disponibles sur les vitesses de lectures et d'écriture, il doit être possible de faire des simulations. Une application pratique de cette règle, que l'on trouve dans de nombreuses chartes est le fait de présenter chaque pièce jointe. Il est recommandé, lorsqu'on inclut un document Word, de mettre un résumé de quelques lignes qui explique le contenu de la pièce jointe. Si cette règle a émergé dans de nombreuses entreprises, on peut conjecturer qu'elle est efficace. On peut aussi essayer de le démontrer, si l'on dispose d'une indication statistique sur le nombre de fois ou l'on ouvre une pièce jointe sans intérêt (du point de vue du destinataire). On pourra remarquer que cette règle est due à la lenteur de l'ouverture d'un document joint, et que la longueur du résumé doit être inversement proportionnelle à l'efficacité du PC du destinataire J

(5) Lien entre le « early packet discard » et l'abandon d'email.

Un ami m'a fait remarquer la similarité entre le protocole de routage IP dans lequel le routeur commence à perdre des packets de façon progressive avant d'arriver à la saturation de ses buffers. Cela permet aux protocoles astucieux, de type TCP, de détecter ces pertes et de s'adapter en terme de routage ou de débit. Le fait de ne pas répondre aux emails fonctionne en effet de façon semblable : ne pas répondre rapidement, ou du tout, est une façon efficace de signaler « au système » que l'on est saturé. C'est d'ailleurs la seule solution « auto-adaptative » lorsque le trafic email devient trop important. Cependant, le fait que ce « protocole » fonctionne ne le rend pas désirable pour autant, et je persiste à penser que la limitation du trafic à la source est plus efficace J

(6) LEMM et outils

Patrice me demande s'il faut aborder le sujet de l'efficacité par les outils. Cela dépend ce que l'on appelle un outil. Je ne fais aucune hypothèse sur l'outil de courrier électronique. Je m'intéresse simplement à un canal asynchrone, multi-destinataires explicites, avec boite de stockage. Tout ce que j'écris s'appliquerait de la même façon à du courrier physique, à des messages Facebook, etc.

Précisément l'approche SIFOA que je développe consiste à faire une abstraction de chaque canal de communication (sync/async, nombre de destinataire, vitesses de lecture/écriture, stockage, latence …) pour pouvoir ensuite comprendre et comparer l'apport de chaque canal.

L'intérêt d'une telle approche, que je qualifie de systémique (parce qu'elle cherche à étudier la communication d'entreprise en tant que système), est de donner des propriétés qui sont vraies de façon générale. Par exemple, ce que je cite comme « insight du lean », le fait que la variabilité du temps de réponse augmente avec le taux de charge, est vrai indépendamment de l'outil ou de la règle que les agents utilisent pour gérer leur boite aux lettres.