Introduction à la tournée du laitier

Introduction à la tournée du laitier

Traduction du billet « Introduction to milk runs » de Christoph Roser sur son blog All about Lean.

La tournée du laitier est un concept populaire pour la livraison de pièces au sein d’une usine et même entre plusieurs usines. Il repose sur la philosophie du flux tiré, de la réduction des stocks et de la simplification de l’approvisionnement en pièces.

Cependant, elle ne convient qu’aux produits fabriqués en série, ou plus précisément aux composants identiques et aux pièces identiques, même s’ils entrent dans différentes variantes de produits. En outre, elle peut également être utilisée avec le kitting[1]. Commençons par une introduction sur la tournée du laitier.

Lire la suite « Introduction à la tournée du laitier »

Tout ce que vous avez toujours voulu savoir sur l’andon dans l’IT par Marie-Pia Ignace

Tout ce que vous avez toujours voulu savoir sur l’andon dans l’IT par Marie-Pia Ignace

Tirer l’andon dans une usine de production automobile provoque l’interruption de la chaîne de production. Et dans l’IT ? Et bien quand on fait du Lean IT, on s’arrête aussi dès que l’on voit un défaut.

A la différence de la rétrospective qui intervient tardivement après le problème, l’andon permet de s’attaquer à la résolution du problème immédiatement !

Dans cette présentation de Marie-Pia Ignace à Flowcon 2022, découvrez les formes que prennent l’andon dans l’IT avec des exemples concrets issus de différents métiers : https://youtu.be/fVJ40gAoNYU

andon dans l'IT

Vous cherchez à améliorer la fiabilité de vos services IT ?
Vous voulez mettre en place un système d’andon dans votre équipe ?
Contactez-nous au 01 40 05 96 88 ou par email contact at operaepartners point com

Productivité, travail et biais managériaux

Lors de mon service militaire, il nous arrivait régulièrement de déplacer un tas de cailloux du côté Nord Ouest de la cour de la caserne au côté Sud Est, et réciproquement. Cela nous occupait sainement, pensaient les sous-officiers.

Cette sensation de travail inutile, je la rencontre régulièrement dans mes gemba walks. Dans cette équipe de data mining, il s’agit d’évaluer soigneusement chaque demande émise par le marketing, puis d’en préparer la présentation dans un comité chargé d’en valider la réalisation, puis de la planifier et de la replanifier jusqu’à la réaliser … en 90 secondes, le temps de taper 23 caractères dans une requête et de lancer un test simple. Ailleurs, on va demander aux techniciens de maintenance de consacrer des journées entières à mettre des courriers dans des boites aux lettres au lieu d’inspecter et d’entretenir les équipements dont ils ont la responsabilité.

J’ai vu des situations comme celles-ci dans beaucoup d’entreprises. Souvent, elles s’accompagnaient d’un stock de demandes/opérations à traiter qui prenait du retard. Une équipe de développeurs logiciel n’arrivait pas à corriger les bugs qui irritaient les utilisateurs tous les jours, tant ils étaient occupés à développer de nouvelles fonctionnalités, elles-mêmes dépendantes du travail d’autres équipes, et ayant donc une probabilité faible d’être mise à disposition avant 18 mois. Dans un centre d’appels interne avec une qualité de service perfectible, une partie des collaborateurs travaillait sur le sujet suivant : communiquer à l’ensemble des 1 200 manageurs qui récupérait le droit de signature lorsque l’un d’entre eux était en congé. En regardant d’un peu plus près, il est apparu que les notes de service envoyées traitaient des vacances de l’été … précédent.

Ces situations absurdes s’accompagnent pour les collaborateurs d’un sentiment d’épuisement face à un travail sans fin et de perte d’estime de soi, face à l’inutilité de l’action.

Quelle tristesse ! La seule voie de sortie honorable serait d’imaginer réduire ces activités inutiles pour retrouver tout à la fois de la qualité de service, de la productivité et du plaisir au travail.

Et pour cela, le manager doit déjà prendre le temps d’aller sur le terrain, pour voir avec les yeux du lean (le gemba walk) et accepter ce qu’il y découvre. Ce qui sera plus facile avec un coach lean, car les situations perdantes que nous avons évoquées proviennent largement de nos propres biais cognitifs.

Biais numéro 1 : « il faut occuper les collaborateurs »

Ce sont les enfants des centres aérés que l’on doit occuper, et non les collaborateurs de l’entreprise. Eux ont été recrutés pour leurs compétences et on leur demande d’apporter de la valeur, qui se définit d’une façon différente en fonction de l’endroit où l’on travaille. Les planifier de travailler sur des activités sans intérêt n’est pas qu’un coût pour l’entreprise. C’est aussi un facteur puissant de démotivation.

Biais numéro 2 : « travail et productivité sont liés »

Ce biais-là est partiellement juste : sans travail, rien n’est produit et la productivité est égale à 0. Mais quand on travaille, est-on productif ? La productivité se calcule en divisant la valeur fournie par la charge. Travailler sur des devis que l’on n’arrive pas à envoyer, étudier des sinistres que l’on n’arrive pas à régler ou écrire du code logiciel qui ne part pas en production, répondre à des appels que l’on n’arrive pas à résoudre, c’est à la fois travailler et avoir une productivité proche de 0.

Biais numéro 3 : « l’optimisation (si ce n’est l’automatisation) du processus va améliorer la productivité »

Cela dépend déjà de la façon de s’y prendre pour optimiser un processus. Mais même en cas de succès, l’amélioration de la productivité n’est pas au rendez-vous.

En effet, quel est le temps consacré à traiter la demande du client à l’intérieur d’une journée ?

  • 50 % : une équipe de back office a une productivité de 70 opérations par jour et chaque opération dure 3 minutes en moyenne. 70 x 3 = 210 minutes. Une journée de 7 heures représente 7 x 60 minutes, soit 420 minutes.
  • 25 % : une équipe de développeurs passe 5 jours par mois à faire du développement logiciel.
  • 10 % : un agent de maintenance trouve porte close 9 fois sur 10 et peut intervenir 1 fois sur 10

Faut-il s’intéresser à l’efficacité du geste technique ou à tout ce temps perdu en dehors du processus ? A réfléchir au cas par cas, après avoir bien observé la situation.

En conclusion : réconcilier travail et productivité

Si vous souhaitez aller plus loin sur le sujet, voici une ligne méthodologique que propose le lean :

Commencez par définir la productivité de votre équipe. La productivité est par définition égale à la valeur produite divisée par le temps de travail :

  • Commencez par trouver le « point de sortie » du travail de l’équipe et définissez-y la valeur : un virement fait, une commande exécutée, une donnée mise à jour, etc… Ensuite, il suffit de compter à la fin de journée pour avoir la valeur produite. Et de le faire chaque jour.
  • Pour le temps de travail, visez large. Regardez le nombre de personnes dans l’équipe, sans considération de ce qu’elles font (ouvrir le courrier, préparer les reportings, répondre aux appels, archiver et classer, tout compte) et comptez combien de journées de travail cela représente chaque jour. Par exemple, 6 personnes à temps complet et 1 à 80 % présentes lundi, cela donne un temps de travail ce jour-là de 6,8.

Puis divisez. Et regardez comment bouge la productivité au fil des jours. Vous aurez des jours à 0, d’autres à 5, d’autres à 15. Et une moyenne.

L’exercice n’a rien de simple. La notion de valeur est souvent moins précise qu’on ne le croit et l’envie de « tout expliquer » avant d’avoir fait le calcul est pressante. Ne vous laissez pas tenter !

Maintenant que vous avez votre chiffre de productivité sur plusieurs jours, analysez la courbe :

  • Etes-vous surpris par le niveau de productivité ?
  • Comprenez-vous pourquoi un processus que vous connaissez bien a parfois une productivité de 1 et parfois de 6 ?

Et si vous pensez que la situation est perfectible, faites du lean … pour améliorer la productivité, pas le travail.

Vous souhaitez être accompagné pour aller sur le terrain ? Vous aimeriez discuter des situations que vous pensez perfectibles dans votre activité ? Contactez-nous au 01 40 05 96 88 ou par email contact at operaepartners point com

Alliance MIM : comment l’exemplarité d’une pratique lean manufacturing très aboutie inspire le lean dans l’informatique

Alliance MIM : comment l’exemplarité d’une pratique lean manufacturing très aboutie inspire le lean dans l’informatique

J’ai eu la chance immense d’être invité par Jean-Claude Bihr, PDG de l’entreprise Alliance MIM, à une visite de son usine Lean. Il nous a présenté sa société, sa vision du lean, ainsi que les pratiques lean les plus essentielles mises en œuvre depuis 2006 par ses collaborateurs sous son impulsion. Un cas d’école extraordinaire, de par l’exemplarité du dirigeant, la démonstration de l’efficience d’une véritable transformation lean menée à bien, la satisfaction au travail des collaborateurs, le développement du chiffre d’affaires dans un marché concurrentiel mondialisé, et le maintien des emplois sur place, à Saint-Vit, dans le Doubs face à la Suisse. En tant que coach lean, voici ce que j’ai vu, entendu et quelles leçons j’ai pu en  tirer pour améliorer ma pratique du lean dans l’informatique.

Lire la suite « Alliance MIM : comment l’exemplarité d’une pratique lean manufacturing très aboutie inspire le lean dans l’informatique »

Pas de bras, pas de chocolat… Comment bien choisir son futur patron

Pas de bras, pas de chocolat… Comment bien choisir son futur patron

Leader et manager lean, vous changez de poste. Par quoi commencer ? 

Après trois ou cinq années d’efforts et d’amélioration continue, qui ont abouti à des résultats époustouflants obtenus par vos équipes gonflées à bloc, vous vous apprêtez à prendre un nouveau poste, une petite larme à l’œil  et la poitrine gonflée par le vent du large.

Ailleurs, que ce soit dans une autre entité du même groupe ou dans une autre entreprise, vous vous apprêtez à quitter votre joli système lean un peu hors norme, qui tourne comme un coucou suisse, pour un autre quadrant régi par d’autres paradigmes plus traditionnels. Voire carrément normatifs. Aïe !

Ce que le lean vous a apporté, à vous et à vos équipes, est si structurant que vous n’avez pas du tout l’intention d’y renoncer. Comment allez-vous donc bien pouvoir vous y prendre ?

Lire la suite « Pas de bras, pas de chocolat… Comment bien choisir son futur patron »

« Manager lean as a coach » – partage d’expérience lean

« Manager lean as a coach » – partage d’expérience lean

Inès manage une équipe de support informatique qui a en charge la résolution des incidents et la réponse à un ensemble de demandes d’aide arrivant au fil de l’eau. Inès cherche à s’approprier les pratiques managériales du lean :

Lire la suite: « Manager lean as a coach » – partage d’expérience lean

Challenge

Elle a donc défini un premier challenge pour ses équipes : accélérer sur le traitement des incidents, avec comme premier pallier de respecter les engagements de service (SLA) auxquels son service a souscrit.

Exemple de SLA : cinq jours pour retrouver un fonctionnement informatique normal pour des incidents de criticité moyenne.

L’équipe construit sa 1ère mesure : le taux de retard dans la remise en service est de 27 %.
Il y a donc matière à s’améliorer !

Gemba

L’équipe commence par mieux comprendre d’où viennent ces retards. Ils extraient un ensemble d’incidents, les analysent un par un et les organisent en « pareto », c’est-à-dire en piles d’incidents ayant la même caractéristique.

Ils sont surpris de découvrir que certaines familles comportent un nombre significatif d’incidents de même nature, alors qu’ils les croyaient plutôt uniques.

Kaizen

Arnaud, l’un des membres de l’équipe, propose de prendre en charge les incidents liés à la facturation entre l’entreprise et ses clients. Inès se réjouit de voir le kaizen commencer.

Elle continue dans sa posture de « manager as a coach » et cherche maintenant à ce qu’Arnaud comprenne bien l’importance du sujet qu’il travaille avant d’engager l’amélioration. Arnaud arrive à la liste suivante :

  1. Les problèmes de facturation créent des tensions entre l’entreprise et la comptabilité de ses clients,
  2. La législation oblige à un règlement des factures sous 45 jours, délai difficile à tenir s’il y a un incident,
  3. Le département Finance se plaint d’avoir des incertitudes sur la facturation et le chiffre d’affaires.

Une fois l’impact posé, Arnaud entre maintenant dans la recherche de causes.

Dans son gemba, il lui apparait très vite que le standard de traitement des tickets n’est pas respecté. A titre d’exemple, sur l’un des incidents, l’équipe attend une validation externe du « métier » sur une solution très technique, sur laquelle le métier n’a pourtant pas de compétence particulière. Le temps s’allonge et le SLA n’est pas respecté.

D’autre part, les incidents ouverts disparaissent du radar des équipes « métier ». Chacun reçoit nominativement les incidents sur lesquels sa contribution est attendue. Il n’en existe aucune liste récapitulative et, avec un peu d’inattention, les incidents disparaissent. Beaucoup ne savent pas qu’ils ont un incident à regarder et une action à conduire.

Arnaud propose à Inès de retravailler les standards avec les « métiers » puis d’y former leurs interlocuteurs. A titre de pense-bête, il propose aussi de donner à leurs interlocuteurs « métiers » l’accès à leur management visuel du flux des tickets et de faire un point hebdomadaire pour voir s’il y a des problèmes particuliers.

Une fois ces actions conduites, le taux d’incidents hors SLA descend de 27 % à 15 %.
Arnaud en est bien fier.

A la question d’Inès de savoir ce qui l’a le plus marqué dans son PDCA, il explique avoir été très étonné par les impacts concrets des incidents informatiques. Lui voyait une panne comme une panne de machine, et non comme un vrai risque commercial et financier.

L’histoire ne s’arrête pas là

Inès est guidée dans son parcours de manager lean par un coach lean expérimenté. Arnaud et elle profitent d’une de ses visites pour lui présenter le PDCA. A l’issue d’un échange à trois autour des questions du coach, la recommandation qu’il laisse est de réfléchir à deux points :

Question 1 pour Arnaud : Construire et partager un standard a manifestement permis de passer une marche mais il reste encore 15 % des incidents résolus hors SLA. Pourquoi ? Il faut retourner sur le terrain et creuser au-delà des problèmes les plus évidents.

Question 2 pour Inès : Comment faire vivre un standard et son usage sur le long terme ? Au moment où les bonnes volontés se mobilisent pour le construire, chacun progresse dans sa compréhension du processus. Mais ensuite, on oublie, les gens changent et les bonnes pratiques risquent de disparaitre.

Et vous, lecteur, qu’auriez-vous laissé comme question à Arnaud et Inès ?

17 légendes urbaines de l’IT

17 légendes urbaines de l’IT
  1. Trop d’info tue l’info, il faut simplifier :
    Non. Ce n’est pas l’excès mais la rétention d’information qui tue la collaboration, en particulier la rétention involontaire basée sur l’illusion “ce que je sais les autres le savent aussi, il est donc inutile d’en parler”. Et si la réalité est complexe, il est contre-productif de chercher à en simplifier la représentation à outrance. Comprendre ensemble, voir ensemble, agir ensemble.
  2. Pour produire deux fois plus, il faut évidemment deux fois plus de monde.
    Non. Pour produire deux fois plus Il suffit de trouver et d’éliminer à peine 10 % des gaspillages inhérents au fonctionnement aberrant actuel. Démontré des centaines, des milliers, des millions de fois par les millions de personnes qui ont essayé à travers le monde, depuis des dizaines d’années que le lean existe. Mais toujours aussi in-croyable.
  3. Sur un grand projet, on finit toujours par être obligé de sacrifier soit la qualité, soit les délais, soit les coûts.
    Non. Sacrifier la qualité amène immanquablement à sacrifier les délais, donc les coûts. Trois pour le prix d’un seul !  L’illusion du quick and dirty aboutit immanquablement dans les faits à disgusting and so late.
  4. Mieux vaut commencer par le plus compliqué, comme cela tout le reste sera beaucoup plus facile ensuite.
    Non. Il ne viendrait à l’idée de personne de commencer la découverte des mathématiques par le plus compliqué, comme les équations de Shroedinger, de Maxwell, ou de Black et Sholtes, au motif que le théorème de Thales serait plus facile à comprendre ensuite, même si c’est vrai. Et pourtant on continue.
  5. Éviter de rédiger une documentation de toute manière toujours obsolète, c’est éviter un gaspillage.
    Non. Se passer de documentation, en particulier en exploitation, est bien évidemment le meilleur moyen de créer des montagnes d’erreurs à corriger sans la moindre boussole : pour éviter la traversée du Jura une fois, on devra escalader le Mont Blanc chaque jour. Excellent choix, puisque ce sont deux équipes différentes.
  6. La vérité est dans le code et nulle part ailleurs.
    Non. La seule vérité dans le code, c’est qu’il mériterait un bon refactoring qu’on ne trouve jamais le temps de réaliser. Cf point 14.
  7. C’est toujours le plombier précédent qui a fait du sale boulot.
    Oui. Plombier ou dev, PO ou chef de projet, manager ou DSI, il a toujours soigneusement appliqué les 15 autres préceptes en étant convaincu de faire bien.
  8. Les erreurs, en particulier humaines, sont inévitables.
    Non. Presque toutes les erreurs humaines ont une cause racine évitable. Il faut juste chercher un peu plus loin que la simple réponse au premier pourquoi ?
  9. Les incidents de production sont chaque fois différents.
    Non. Si les manifestations d’un incident en production sont très souvent différentes, leurs causes racines tournent toutes autour des mêmes familles de banalités crasses : absence de monitoring, de tests, de maintenance préventive, de gestion de l’obsolescence, de séparation homme-machine, de formation, de formalisation de la connaissance ou de standard. Qui se résument à une seule : absence de budget, donc de volonté, de ne rien céder sur la qualité. Point.
  10. Zéro défaut, c’est juste impossible.
    Non. Dans l’industrie on compte les défauts en ppm (partie par million), quand dans l’industrie logicielle on les compte en ppc (partie par centième, ou encore pourcentage) soit 1 000 000 / 100
    = une tolérance à l’erreur 10 000 fois plus élevée. Impossible, vraiment le zéro défaut ?
  11. Avec une bonne réorganisation, on résout beaucoup de problèmes.
    Non. On n’aura rien amélioré du tout avec une reorg : ni le processus, ni la manière de l’opérer, ni les connaissances des collaborateurs, ni les pratiques managériales, sauf par grand hasard. On aura juste dégradé les réseaux et collaborations informelles existantes et repoussé l’acceptation du problème à la troisième enveloppe.
  12. Le plus important, c’est d’éviter que les gens ne perdent du temps à se tourner les pouces sans rien produire.
    Non. Le plus important, c’est d’éviter que le flux de production ne soit interrompu, ce qui n’a rien à voir avec une soi-disant “optimisation” de l’activité des personnes.
  13. Si on pouvait recruter plus d’experts bien formés, ça irait beaucoup mieux.
    Non. Il n’y a aucun expert disponible dehors ; les seuls experts du sujet sont ceux qui triment chez nous sans répit depuis trois ans sur le sujet. Donc le problème est ailleurs. Peut-être dans le temps riquiqui que nous consacrons à former efficacement ceux de nos collaborateurs moins experts, sans parler des prestataires ?
  14. Charger les gens à 110 % c’est les rendre plus efficients.
    Non. Charger au maximum les équipes, c’est les empêcher délibérément de prendre le recul, i.e. le temps nécessaire pour résoudre définitivement certains de leurs irritants. La plus grande, et la plus classique des erreurs managériales, sans doute possible.
  15. Le plus important dans une réunion c’est de la finir à l’heure pour ne pas démarrer en retard la suivante.
    Non. Dans une réunion l’important c’est de faire participer les bonnes personnes sans en oublier ni en manquer.
  16. Le client ne sait jamais ce qu’il veut, rien ne sert de perdre trop de temps avec lui ; mieux vaut un PO ou une AMOA qui parle en son nom.
    Non. Le client sait très bien ce qu’il veut. C’est nous qui ne nous intéressons pas vraiment à ses usages, au motif fréquent que ce serait vraiment trop “chronophage”.
  17. Il vaut mieux ne pas participer à une réunion d’une heure trente si c’est pour ne s’exprimer que 5 minutes, on aura évité de perdre 1h25 de son temps.
    Non. Il vaut mieux disposer au plus tôt des informations qui nous auraient évité une erreur de conception d’architecture remettant en cause toute la réalisation du projet de 18 mois à dix jours du « go live ».

Une pensée émue pour tous ces grands projets Louvois, Scribe, Sirhen, ONP, LUMM, dégommés dans les rapports de la Cour des Comptes : hommage aux grands projets tombés au champ de déshonneur de l’IT, embourbés dans ces 17 biais cognitifs si bien partagés.


Vous souhaitez être accompagnés ou connaître nos offres ? Contactez-nous à l’adresse contact at operaepartners point com, par téléphone au 01 40 05 96 88 ou avec le formulaire ci-dessous :


Value in – value out

Value in – value out

Fred Mathijssen, Director of Technology de Nike Europe, avait fait afficher dans la salle de son management visuel, en grand :

« 1 euro investi ici rapporte 1 200 euros. »

Il nous a expliqué que le chiffre était parfaitement inexact mais que c’était le résultat du premier calcul de ROI conduit par ses équipes. Embarrassées par l’affichage, les équipes avaient essayé de mieux comprendre quelle valeur apportait l’informatique et, rapidement, le ratio avait diminué pour atteindre un niveau raisonnable, toujours enthousiasmant, et qui restera confidentiel.

Cela m’a amenée à réfléchir à une notion de « valeur in – valeur out » :

  • Valeur in : est-ce que je suis capable de produire la même valeur, avec des moyens internes (« in ») plus faibles ?
  • Valeur out : est-ce que j’apporte plus de valeur aux bénéficiaires de mes services ?
Lire la suite « Value in – value out »

« On ne nous a jamais dit que la qualité c’était important avant de mettre en prod »

« On ne nous a jamais dit que la qualité c’était important avant de mettre en prod »

C’est l’histoire de 3 équipes super. 3 équipes dans 3 entreprises radicalement différentes. 3 équipes dans 3 villes différentes. 3 équipes qui ne se connaissent pas mais qui ont en commun d’avoir la responsabilité de mettre en production un gros système sur lequel elles travaillent depuis 2 ans.

Et sur lequel elles ont beaucoup travaillé, n’ont pas compté leurs heures. Les membres de ces équipes voulaient tous réussir leur projet, faire réussir leur entreprise et livrer le projet à la date promise, « respecter la deadline », « le time to market », « la date de mise en prod ». Ils ont donc codé, débuggé, corrigé, recodé, testé, corrigé, re-livré (parfois le soir, la nuit, le week-end)… et fiers d’arriver devant leur comité de pilotage à temps – certes avec des bugs, « mais pas tant que ça ! » pour présenter leur projet, leur bébé… ils se sont vu recevoir un « NO GO » en pleine face.

Lire la suite « « On ne nous a jamais dit que la qualité c’était important avant de mettre en prod » »

Comment diviser par 4 le temps de cycle des user stories ? Rendez-vous le 21 avril à 19 heures

Comment diviser par 4 le temps de cycle des user stories ? Rendez-vous le 21 avril à 19 heures

Venez écouter Tycho Tatitscheff, architecte développeur chez BAM expliquer comment il est parvenu à atteindre le zéro bug en travaillant sur la dette technique et les meilleures pratiques de développement logiciel selon la démarche Lean IT.

BAM est l’agence experte du développement de solutions business sur mobiles.

Ce meetup se déroulera à partir de 19h le 21 avril chez Operae Partners à Paris 19e et à distance sur Zoom.

Inscrivez-vous ici : https://www.meetup.com/fr-FR/Lean-IT-Paris/events/284924321