dimanche, décembre 06, 2009

Lean eMail et Loi de Little

Je reviens aujourd'hui sur un de mes sujets favoris : le « lean eMail Management» (LEMM), c'est-à-dire l'approche lean appliquée au courrier électronique. Je vais aujourd'hui enrichir ma réflexion par un peu de systémique appliquée, d'où la référence à la Loi de Little, la célèbre formule des files d'attentes.

Dans mon post de Novembre 2007 (deux ans déjà !) j'ai proposé de déduire de l'approche lean quelques principes de gestion des emails, et plus précisément des principes pour réduire les flux. Le point de départ de cette nouvelle réflexion est la consultation de l'excellente « Charte pour un bon usage des messageries électroniques dans un cadre professionnel », un document en projet produit par l'ORSE (Observatoire sur la Responsabilité Sociétale des Entreprises) qui sera bientôt rendu public

Je ne vais pas parler de ce document avant qu'il soit rendu public mais son introduction réaffirme des idées qui sont dans l'air du temps (et que l'on retrouve dans le Chapitre 5 de mon livre) : le courrier électronique est sorti de sa « zone de confort », nous écrivons et recevons trop de mails, ce qui prend trop de temps (plus de deux heures par jour pour la moitié des personnes interrogées dans une étude) et provoque une surcharge cognitive (ce qu'on appelle le trafic mental dans les techniques de gestion des priorités). Une des références sur le sujet, citée par Jean-Pierre Corniou dans mon commentaire sur le Lean Worker, est l'article « surcharge organisationnelle, urgence et TIC » de H. Isaac, E. Campoy, M. Kalika. D'une part, les études montrent que nous passons beaucoup de temps à surveiller notre boite email, et d'autre part, chaque interruption (aller lire subrepticement l'email qui vient d'arriver) nous coûte : 64 secondes pour reprendre le fil de sa pensée, et 10 points de QI selon l'étude de l'université de Londres que j'ai citée plusieurs fois. De plus, une boite email trop remplie augmente le temps que nous mettons à répondre (je vais y revenir, c'est l'application directe de la loi de Little) et augmente ce que les consultants en efficacité appelle le « rework » : refaire plusieurs fois la même chose (par exemple, relire plusieurs fois l'email que nous décidons de remettre à plus tard). Très logiquement, ce post va reprendre la question « comment éviter les boîtes trop remplies », sous l'angle de la systémique.

Cette approche me conduit à développer 4 principes, dans la suite du post précédent, mais en affinant l'aspect analytique. Aujourd'hui je vais me contenter de poser les principes de l'analyse, mais il est facile de voir qu'il y a matière à simulation et à faire passer dans une dimension quantitative. Dans un franglais ignoble, voici la liste :

  • JIT email : l'email juste-à-temps, qui n'utilise pas la boite comme espace de stockage temporaire
  • Spelled-out email : l'email construit et rédigé, qui simplifie la tâche du lecteur
  • Email Protocol : réguler le flux des emails qui donnent du travail au lecteur
  • Reduire le email span : Il existe d'autres outils que l'email pour « avoir plein d'amis », il vaut mieux rester sur un réseau raisonné.

Rappelons la Loi de Little :

N = l x T, ou N est le nombre d'emails dans la boîte, l est le taux d'arrivée, T le temps total de séjour (traitement inclus).

Nous voyons tout de suite de nombreuses pistes pour réduire N J

1. Just-in-time email

La première façon de réduire N, c'est de réduire T, et la première façon de réduire T c'est de réduire la partie "attente avant traitement". On retrouve très logiquement un des principes du lean manufacturing qui a donné le « juste à temps ». Le JIT email, c'est celui qui arrive dans la boîte aux lettre au « bon moment », ni trop tôt (parce qu'il encombre) ni trop tard (parce qu'on n'a plus le temps de le traiter).

Il y a plusieurs degrés de maîtrise dans cette approche :

  1. Ne pas pousser un mail trop tôt « pour s'en débarrasser » (réduire son trafic mental en augmentant celui des autres)
  2. Lorsqu'on demande quelques chose dans un email, donner une indication claire de la fenêtre de temps de la réponse attendue (ce qui favorise l'application de (1))
  3. Lorsqu'on demande quelque chose, prendre la disponibilité du destinataire en compte ! Cela peut se faire dans un monde 2.0 avec des indicateurs de présences, des statuts, l'utilisation de l'IM … mais cela se fait aussi avec un bon vieux coup de fil avant de pousser une pièce jointe de 10 pages à relire.

Le JIT email ne peut pas exister comme pratique autonome, c'est la déclinaison au courrier électronique de la pratique lean dans le monde des knowledge workers, consistant à ne pas pousser la charge de travail, mais à la « tirer ». Je fais une différence implicite entre le message de deux lignes (type statut de Facebook) qui peut être poussé, et le message qui requiert une réponse et un travail (temps de traitement important).

Une petite remarque pratique, basée sur une technique que j'applique depuis quelques années. Pour développer le JIT du coté du lecteur et surtout pour éviter le « rework », je m'astreins à colorer chaque email (merci Outlook) à la première relecture avec un code couleur selon la priorité :

  • Jaune, orange, rouge : nécessite une réponse – c'est de la procrastination, mais organisée J
  • Vert : information – je laisse l'email dans la boite, car je n'ai pas envie de le ranger ailleurs, mais il ne nécessite aucun traitement
  • Violet : tâche en cours – rien à faire pour l'instant, mais cela reviendra (par exemple lorsqu'un collaborateur m'aura répondu)

Tout email qui n'est pas coloré est détruit, et je ne fais pas deux fois l'acte de coloration. J'estime avoir gagné de 10 à 20% dans mon temps de traitement des emails.


2. Spelled-out email

La deuxième piste pour réduire T est de réduire le temps de traitement et de s'attaquer à l'asymétrie qui existe entre celui qui écrit et celui qui reçoit. L'urgence pousse à envoyer des demandes mal formulées :

  • Abus de pièces jointes
  • Message « pour information »
  • Questions mal explicitées
  • Etc.

Ce n'est pas que la mauvaise volonté qui conduit à pousser « la charge de traitement » sur le destinataire : on écrit moins vite qu'on ne lit. J'ai déjà abordé ce sujet dans mon livre et dans un post précédent.

La pratique du « spelled-out » email, qui est encouragée par la plupart des chartes (dont celle rédigée à Bouygues Telecom lorsque j'étais DSI), consiste à déplacer une partie du travail sur le rédacteur de l'email, en lui demandant de mieux préparer son courrier pour faciliter le travail du lecteur. Le bénéfice systémique est double :

  • Puisqu'il faut plus de temps, cela réduit le nombre d'emails produits J
  • On gagne en temps de traitement, et par application de Little, on réduit la taille des boites et on augmente la rapidité.

Cet argument s'applique également pour comparer l'email avec d'autres canaux de communication. Laisser un message vocal est encore plus asymétrique : cela demande peu d'effort pour celui qui laisse le message (on parle plus vite qu'on n'écrit), mais cela prend plus de temps pour celui qui reçoit (on lit plus vite qu'on écoute). C'est ce qui fait l'intérêt d'un service de « speech-to-text » comme celui de Spinvox. Au contraire, la communication au travers d'un blog d'entreprise exige un effort plus important de celui qui écrit (et je suis bien placé pour le savoir). L'intérêt principal de la communication par blog vient avant tout du concept de « Broadcasting ciblé », mais il y a également un bénéfice systémique de « préparation du contenu ».


3.Email Protocol

Revenons au cas d'un email qui contient une demande qui exige un travail (temps de traitement significatif). L'application de l'approche lean exige de vérifier la « disponibilité » du destinataire, c'est un cas particulier et plus fort du JIT. Quelque soit la méthode ou l'outil, il faut s'assurer en amont que celui qui reçoit la demande dispose du temps pour la traiter. C'est ce que j'appelle le « email protocol » : il faut un protocole qui définisse de quelle façon je peux envoyer au destinataire un email qui va lui prendre 1heure ou 1 jour de travail. La théorie des files d'attentes va nous aider à justifier cette affirmation forte. Que se passe-t-il lorsque le nombre d'emails significatifs (avec temps de traitement) augmente ?

  1. Dans un premier temps, le temps de lecture augmente (cf. les 2 heures mentionnées en introduction). Cette augmentation a un fort impact sur le temps utile de travail personnel, qui diminue d'autant. Compte tenu du temps passé en réunions, déplacements, travail administratif, c'est une perte sensible d'efficacité, qui paradoxalement augmente le temps de traitement des emails les plus complexes qui exigent ce travail personnel. On retrouve la loi simple des file d'attentes : le temps de service augmente lorsque le taux d'occupation croit (facteur 1/(1-A))
  2. Dans un deuxième temps, la boite devient un outil de triage des priorités. Les messages attendent en fonction de leur priorités, suivant une loi qui est souvent exponentielle dans les modèles de « decay » (e^-kt). La probabilité d'être traité décroit en fonction du temps, soit jusque l'oubli, le dépassement de la deadline, ou l'abandon. C'est la seule réponse systémique lors de l'inflation non contrôlée du nombre d'emails, puisque, pour la plupart des gens, il faut aussi travailler J Au défaut systémique de l'allongement de la latence s'ajoute alors les taux de pertes, car tôt ou tard des erreurs de priorisation se produisent (ce que nous savons tous lorsque notre boîte devient trop volumineuse).

Le problème ne vient pas seulement de la longueur de la pile de messages, mais aussi de sa dispersion. Si le taux de charge augmente trop (pas assez de temps « libre » pour jouer le rôle de buffer pour absorber l'irrégularité des demandes), la taille de la pile fluctue et le temps de service en conséquence (voir les courbes dans cet article). De la même façon cette irrégularité du temps de traitement augmente la taille moyenne de la pile, selon la Formule de Pollaczek-Khinchine (voir le rôle de Cs dans la formule : plus cette variation de service augmente, plus la file d'attente s'allonge).

On retrouve une intuition géniale du lean : un système couplés de file d'attentes n'offre aucune garantie de temps de service si les files sont trop chargées. Dans un monde ou les boites emails sont pleines, la même demande qui représente 10 minutes de travail peut recevoir une réponse en une heure comme en une semaine, même si elle est prioritaire.

Une fois de plus, nous nous retrouvons dans une situation de « tragédie des communs ». D'un point de vue individuel, chaque envoi d'email (dans le cas d'un « email requête ») est justifié par la recherche d'un surcroit d'information (même avec une faible probabilité, cela reste un gain). En revanche, de façon globale et systémique, ces envois supplémentaires bloquent le système global : (1) le temps d'attente augmente, puis, (2) la qualité et la probabilité d'obtention de la réponse diminue. La réponse au paradoxe de la tragédie des communs est, classiquement, la régulation. C'est pour cela que je supporte la charte pour un bon usage préparée par l'ORSE.


4.Email Span

Pour finir, nous pouvons introduire le diamètre du réseau social associé, en définissant le nombre moyen de destinataires que chaque personne touche en un mois. Cette approche est semblable au diamètre réunionel introduit dans ce blog et développé dans mon dernier livre (et en particulier en annexe). Il se trouve que la même loi s'applique à nouveau ! La vitesse de propagation de l'information est fonction de deux choses : le nombre d'étapes pour qu'une information passe de la source au destinataire final, et le temps qu'il faut pour chaque étape, qui est précisément le T que nous avons introduit plus haut. En première approximation :

  • Le nombre d'étape est proportionnel à log(DI) / log(De) (même raisonnement que pour les réunions, DI étant le diamètre informationnel)
  • T est proportionnel à la taille de la pile ou du nombre de messages, soit globalement De.

On retrouve une formule en (De/Log(De)), qui nous indique que plus on parle à un réseau étendu, moins l'information se propage vite, car la bande passante de lecture de chacun étant constante, la partie affectée à chaque emetteur décroit comme (1/De). C'est la même remarque qui permet de comprendre la limite des «organisations plates » (lorsqu'on a 30 N-1, la fréquence à laquelle on peut les rencontrer décroit fortement !).

Nous aboutissons donc à une tension constructive :

  • Pour décloisonner l'organisation il faut ouvrir les réseaux et augmenter le diamètre de chaque employé
  • Pour augmenter l'efficacité, il faut conserver des petits groupes fortement connectés avec une haute fréquence

La solution de ce dilemme est précisément l'entreprise 2.0 ! Plus précisément, il faut introduire l'intermédiation propre aux canaux 2.0 tels que les blogs, les micro-blogs ou les walls. Le principe d'intermédiation, associé au broadcast sélectif, consiste à remplacer le pattern :

X –(z)-> Y (X transmet l'info z à Y)

Par :

X -> Z <- Y (X publie l'info z, et Y vient la lire si cela l'intéresse)

L'avantage évident est de pouvoir décloisonner (toucher un public large) sans consommer une part indue de la bande passante collective, ce qui arriverait si j'envoyais lundi cet excellent texte à cent collaborateurs de mon entreprise, sous le prétexte que le courrier électronique est un sujet qui les intéresse. Dans une entreprise 2.0, on peut restreindre l'usage de l'email à un réseau plus restreint sans perdre en efficacité (cf. l'usage de l'email sous Facebook avec un réseau fermé d'amis, qui devient l'outil asynchrone favori des ados au détriment de l'email classique).

Conclusion : A Suivre …

Ce post marque une étape dans ma réflexion sur le LEMM mais je suis loin d'avoir fait le tour de la question ! Cette vision systémique appelle une simulation, dans le cadre de mon projet de simulation des flux d'information et d'architecture organisationnelle (SIFOA). Ce type de simulation devient de plus en plus pertinente car la sociométrie du courrier électronique commence à exister (cf. mon plaidoyer pour la sociométrie de la collaboration d'entreprise). C'est un des intérêt du rapport de l'ORSE, il cite des vraies études avec des vrais chiffres.

Pourquoi escalader la complexité de la démarche en passant à la simulation ?: parce qu'il faut des réponses quantitatives, il n'y a pas de vérités universelles ! Le courrier électronique est un outil remarquable, c'est son abus ou sa mauvaise utilisation qui pose problème.



2 commentaires:

  1. bonjour,

    Je vais positionner cette réponse dans l'optique d'un Knowledge Worker utilisateur d’une méthode de gestion de ses actions assez globale (pas simplement ses mails) telle que GTD ( http://fr.wikipedia.org/wiki/Getting_Things_Done ) et rebondir sur deux phrases de ce post. GTD est porteur de la logique que tout est flux d'informations qu'il est nécessaire d'analyser pour ensuite décider de ce qu'on en fait. C'est le "stuff qui s'accumule dans sa/ses "inbox(es)" et qu'on analyse lors de revues programmées régulièrement et lors desquelles on décide principalement de l'action à faire et de son contexte (être devant son PC, devoir être en tête à tête avec son patron, en salle informatique, au téléphone, en réunion d'équipe...). A noter qu’il n'est pas nécessaire d’analyser des mails en temps réel, au fur et à mesure qu’ils arrivent, ou alors c'est que les deux correspondants se trompent d'outil ; il vaudrait mieux qu'ils utilisent de l'IM ou le téléphone mais peu importe.

    "On retrouve une intuition géniale du lean : un système couplés de file d'attentes n'offre aucune garantie de temps de service si les files sont trop chargées. Dans un monde ou les boites emails sont pleines, la même demande qui représente 10 minutes de travail peut recevoir une réponse en une heure comme en une semaine, même si elle est prioritaire."

    Prioritaire pour qui ?

    Pour notre KW, lorsqu'il tombera sur ce mail correspondant à une action de 10 mn, il la traitera :
    - pas tout de suite ; elle fait 10 mn, seules les actions de 2 mn ou moins sont faite immédiatement, si le contexte le permet,
    - quand, bien entendu il disposera de 10 mn au moins, (il peut certes décider que passer 10 mn à faire cette action tout de suite est plus important que de dépiler ses autres mails, autrement dit que faire la revue de son stuff @inbox qui n'est jamais aussi qu'une action comme une autre).
    - quand le contexte nécessaire à la réalisation le permettra (être devant son PC, devoir être en tête à tête avec son patron...)
    - et qu'il aura "confronté" cette action avec toutes les autres afin de déterminer si elle lui semble prioritaire entre toutes les autres. --> Cette "priorité" ; soit elle aura été déclarée dans le mail de demande (on se trouve effectivement dans une logique de protocole, ce qui n'empêche pas le libre arbitre de celui/celle qui réalise l'action en comparant cette priorité à celles de tous ses autres objectifs/engagements), soit le sujet exposé dans le mail fait que le KW rattache l'action à un objectif et une priorité déjà connus de lui, pas forcement celle de son interlocuteur.

    ...

    RépondreSupprimer
  2. ...suite...

    "Ce post marque une étape dans ma réflexion sur le LEMM mais je suis loin d'avoir fait le tour de la question ! Cette vision systémique..."

    Concernant le coté systémique, la messagerie n'est qu'une inbox parmi d'autres contenant une partie du "stuff" à analyser et éventuellement à traiter par notre KW. Les autres inbox en question sont : ses sms, les papiers qui trainent dans ses poches, les posts des blogs qu'il lit (et auxquels il décide de répondre comme je le fais maintenant), les notes prises en réunion, l'IM, les idées qui lui viennent, etc...
    Du coup pour que la simulation porte réellement sur l’ensemble du système du KW, ce sont toutes ses inboxes qu'il faut prendre en compte et pas uniquement la messagerie.
    Le KW n'est pas en permanence devant sa messagerie mais plutôt face à de multiples flux d'informations, qui sont les matières premières qu'il doit travailler.

    En conclusion, je ne suis pas persuadé que prendre le sujet par les outils soit le plus indiqué, ou alors pour les benchmarker les uns les autres. Les outils, ici le mail, sont plutôt à préconiser pour un type ou un autre de flux. Charge à la méthode de traitement de ces flux, ici GTD, d'être la meilleure possible et de savoir les prendre tous en compte. S'il faut mesurer le LEMM pour le comparer à d'autres méthodes (le mail vs facebook pour un usage donné), je pense qu'il faut surtout mesurer le processus de traitement, GTD par exemple car il a l'avantage d'être formalisé, et faire varier les outils porteurs des flux d'informations entrant afin de voir quel est le plus efficace dans un domaine d'action particulier.

    Patrice

    RépondreSupprimer