La (vraie) différence entre flux poussé et flux tiré

Traduction de “The (True) Difference Between Push and Pull” avec la permission de Christoph Roser de AllAboutLean.com.

Illustration courante, mais trompeuse, de push et pull.

Ce qui différencie principalement le lean des autres types de production c’est l’utilisation de la production « tirée » plutôt que « poussée ». Alors que presque tout le monde sait (du moins en théorie) comment la mettre en œuvre en utilisant le kanban, les différences fondamentales sous-jacentes sont un peu plus floues. Mais qu’est ce qui différencie précisément le flux « poussé » du flux « tiré » ? En outre, qu’est-ce qui rend les systèmes de traction si supérieurs aux systèmes poussés ?

Il s’avère que la plupart des définitions vont dans la mauvaise direction. Même les noms push (poussé) et pull (tiré) ne sont en fait pas bien adaptés pour décrire le concept. Les illustrations courantes ne le sont pas non plus, y compris celle juste au dessus.

Lire la suite « La (vraie) différence entre flux poussé et flux tiré »

Lean management et vente à distance

Lean management et vente à distance

Dans le domaine de la vente à distance, nous avons accompagné des managers dans leurs résolutions de problèmes. Un des PDCA portait sur une perte de chiffre d’affaires car les télévendeurs n’exploitaient pas toutes les opportunités de vente. Dans ce cas précis, on parle d’un montant de 600 000 euros de ventes non réalisées par une équipe de 12 télévendeurs.

Lire la suite « Lean management et vente à distance »

DevOps en pratique : comment réduire le Mean Time To Repair

DevOps en pratique : comment réduire le Mean Time To Repair

Bien souvent je travaille avec des équipes, agiles ou non, dont l’attention se porte naturellement sur la fourniture de nouvelles fonctionnalités. Or, dans cette course à la production de valeur pour rester compétitif face à la concurrence, les équipes doivent faire un choix. Elles se retrouvent régulièrement dans cette situation compliquée où il faut faire un compromis entre développer une nouvelle fonctionnalité ou corriger des anomalies.

Sous la pression du marché, le choix se porte un peu trop souvent sur la livraison de la nouvelle fonctionnalité. La dette technique s’accumule et imperceptiblement le nombre d’anomalies augmente. Et par conséquent les délais de résolution, avec les conséquences qui en résultent sur la satisfaction des clients et du métier, ainsi que sur le moral des équipes. Ceci est contraire à l’esprit DevOps qui préconise de travailler sur 4 indicateurs clef dont l’un est le « Mean Time To Repair » (MTTR – cf Wikipedia), le temps moyen de réparation.

Je vais vous expliquer comment je traite ce problème dans une équipe produit avec certaines pratiques de DevOps s’appuyant sur le management lean dans l’IT.

Lire la suite « DevOps en pratique : comment réduire le Mean Time To Repair »

Scrum et le Toyota Production System, comment construire des équipes ultra performantes

 

 

 

 

 

 

 

 

 

 

 

L’objet de cet article publié par Pierre Jannez sur InfoQ est de montrer comment l’utilisation du Toyota Production System, comme système de construction de la connaissance, permet de révéler les sujets d’apprentissage sur lesquels travailler pour développer des équipes Scrum exceptionnelles pour des résultats exceptionnels.

Pierre y explique :

  • l’importance de construire le bon management visuel pour mieux comprendre la situation et la performance ;
  • de quelle manière envisager la production avec le flux tiré et le Jidoka pour révéler les bons problèmes ;
  • comment résoudre ces problèmes avec la méthode scientifique du PDCA pour développer les compétences des collaborateurs.

Lire la suite « Scrum et le Toyota Production System, comment construire des équipes ultra performantes »

De la résolution de problèmes au Kaizen

kaize6points

Le développement des personnes est au cœur de la démarche lean. Développer en temps et en heure des produits incroyables que les clients adorent nécessite des collaborateurs impliqués et engagés dans l’amélioration continue de leur performance, comme les sportifs de haut niveau peuvent le faire. Tous les outils fournis par le Toyota Production System ont un seul et unique objectif, aider les collaborateurs à identifier les gestes qu’ils ne maîtrisent pas totalement pour leur donner la possibilité de faire de la résolution de problèmes et ainsi améliorer eux-mêmes leurs méthodes de travail et progresser vers l’excellence. Lire la suite « De la résolution de problèmes au Kaizen »

La réduction des incidents informatiques, une priorité pour les grandes banques européennes.

La réduction des incidents informatiques, une priorité pour les grandes banques européennes.

Plus de transparence sur les incidents informatiques

Les banques britanniques doivent depuis le 15 août indiquer sur leur site web le nombre d’incidents informatiques ayant provoqué des interruptions des services de paiement. On découvre ainsi selon le journal les échos du 17 août 2018, que les cinq plus grandes banques du Royaume-Uni ont indiqué avoir connu 67 incidents ayant provoqué des interruptions de leurs services de paiement. De son côté, depuis l’été 2017, la Banque Centrale Européenne impose aux 130 banques de la communauté de rendre public les incidents informatiques majeurs. Ces mesures visent en premier lieu à protéger les clients d’un incident critique qui pourrait avoir des conséquences financières importantes pour les particuliers et les entreprises. Cette obligation de transparence influe en outre directement sur la réputation des banques. L’amélioration de la qualité des applications et des systèmes d’information devient pour les banques un enjeu stratégique majeur. Lire la suite « La réduction des incidents informatiques, une priorité pour les grandes banques européennes. »

Où sont passées les valeurs du Manifeste agile ?

agile-manifesto-lean-operae-partners

Les directions informatiques (DSI) doivent s’adapter aujourd’hui à un monde volatile, incertain, complexe et ambiguë : les situations évoluent de manière imprévisible, de nouvelles technologies ou réglementations peuvent surgir à tout moment et modifier brusquement l’environnement, les interactions entre systèmes se multiplient augmentant le risque d’erreur.

Dans ce contexte d’incertitude extrême, les DSI doivent donc trouver de nouveaux modes de fonctionnement plus flexibles et plus efficaces pour soutenir l’entreprise face à la concurrence.

Pour répondre à cet impératif, certaines se tournent vers une nouvelle forme d’organisation, l’organisation agile. Cette énième transformation consiste le plus souvent à s’appuyer sur un framework agile comme Safe par exemple ou à copier-coller ce que d’autres on fait. Ainsi il est fréquent de voir le modèle Spotify appliqué dans des contextes très éloignés de l’écoute musicale sur internet. Ce changement majeur pour la DSI est mené, généralement, par des coachs agiles rompus à la méthode Scrum et aux outils de facilitation en tout genre. Des équipes autonomes pluridisciplinaires émergent emmenées par des Product Owners et des Scrum Masters (dont le métier est plus de « energizer » les équipes plutôt que de s’intéresser aux pratiques d’ingénierie logicielle et à la qualité du code). Le travail est cadencé au rythme des cérémonies voulues par la méthode : standup meeting, sprint planning, rétrospectives… L’effort de coaching se porte principalement sur l’adhésion des collaborateurs à la nouvelle organisation du travail, sur la collaboration et sur les relations interpersonnelles. Ainsi, la réussite de la transformation se mesure-t-elle à la capacité de chacun à respecter les principes de la méthode et à les mettre en œuvre de manière autonome.

Et quid de la satisfaction client,
de la qualité du code et du respect des délais ?

Mais est-ce suffisant pour obtenir des résultats concrets ? C’est à dire des résultats montrant une meilleure santé de l’entreprise : des clients satisfaits, une augmentation de la qualité délivrée, une réduction significative des délais de production, des coûts maîtrisés, des salariés épanouis…

Le problème est que cette nouvelle transformation ne diffère pas tellement des autres. Les collaborateurs changent de bureau, d’équipe, de contexte applicatif et l’intitulé de leur poste est adapté au nouveau paradigme. Quant à leur travail, fondamentalement il reste le même. Les cartes sont rebattues, mais finalement où est le véritable changement ? Est-ce que cette transformation permet de mieux comprendre le client, de mieux répondre à ses attentes ? Est-ce que les collaborateurs sont plus au fait des plaintes exprimées par les utilisateurs de leurs applications ? Est-ce qu’une attention particulière est portée aux pratiques d’ingénierie (code, architecture, réseau, sécurité…) ? Y-a-t-il un lien clairement identifié entre les attentes des clients, l’ingénierie et la performance de l’entreprise ?

Se lancer dans une transformation agile ne peut donc se limiter à un énième changement d’organisation et à l’application d’une méthode. Pour répondre à l’accélération des changements, la transformation se doit de développer un système d’apprentissage permettant aux collaborateurs :

1 – de développer une compréhension très fine des attentes de leurs clients ;

2 – de voir très rapidement les obstacles qui les empêchent de satisfaire ces attentes ;

3 – de développer des compétences en résolution de problèmes, individuelles et collectives, pour améliorer la situation par eux-mêmes.

Il s’agit dès lors de s’intéresser précisément à la qualité du code, son architecture, sa maintenabilité, sa performance, de chercher à comprendre dans quelle mesure les interfaces utilisateur répondent parfaitement au besoin des clients, et s’assurer que le système est suffisamment sécurisé pour protéger les données sensibles par exemple.

Les auteurs du Manifeste agile  écrivaient en 2001 en préambule :

Nous découvrons comment mieux développer des logiciels par la pratique et en aidant les autres à le faire.

Ces fondements inscrits il y a 17 ans ont malheureusement disparu des pratiques de ceux qui déploient aujourd’hui une forme d’agilité à grande échelle.

Comment revenir aux fondamentaux ?

En recherchant inlassablement à mieux comprendre ses clients et en soutenant l’esprit kaizen à tous les niveaux pour améliorer ses processus et ses pratiques de développement au sens large, obstacle après obstacle, la DSI développe l’expertise de ses collaborateurs et améliore sa capacité à :

1 – concevoir les produits demandés par les clients et les utilisateurs ;

2 – livrer à l’heure les fonctionnalités demandées avec un très haut niveau de qualité ;

3 –  produire des architectures logicielles sécurisées de plus en plus flexibles s’adaptant extrêmement rapidement aux conditions versatiles du marché.

Grâce à cette nouvelle capacité d’apprentissage, la DSI va contribuer de plus en plus efficacement à la compétitivité de l’entreprise en s’adaptant toujours plus rapidement aux nouvelles conditions afin de fournir de meilleurs produits ou services en temps et en heure (du code de qualité, sécurisé et robuste).

 

Le Gemba client : une nécessité, épisode 2

Rappel de l’épisode précédent :

Une des pratiques fondamentales du Lean consiste pour l’entreprise à comprendre la valeur de ses produits ou services du point de vue de ses clients. Cette pratique s’apprend sur le terrain, sur le gemba, là où les choses se passent. Pour découvrir ce que les clients attendent, pour comprendre ce qui les fait rêver, il est nécessaire d’aller à leur rencontre. Pourquoi la pratique du Gemba client est une nécessité : récit d’une expérience client qui a débuté le 31 mars.

Ne me faites pas perdre mon temps :

Jeudi 6 avril, 6 jours plus tard : Cette histoire commence à m’agacer. Je me rends à mon appartement récupérer l’avis de passage. Arrivé sur place force est de constater que, de l’avis de passage, il n’y en a que l’idée. Zut ! Je n’ai pas mis mon nom sur la boîte aux lettres. Donc le colis se trouve au bureau de poste. Sans avis de passage je ne pourrais pas le récupérer. Je pars chez mon client. A la pause déjeuner, je me résigne. J’appelle le service client de l’opérateur. Ça sonne, la voix nasillarde du serveur vocale égrène ses options. Je vais jusqu’à l’épuisement des possibilités. Il n’y a pas l’option « Posez votre question à un conseiller ? ». Je raccroche. Je recommence. C’est de ma faute. Je n’écoute pas avec suffisamment d’attention. J’ai trouvé, enfin, un humain pour me parler. Yes ! J’avoue qu’à ce moment un sentiment d’allégresse m’effleure. Bonjour Madame… Bonjour Monsieur que puis-je pour vous ? J’explique. Silence… Question. Je réexplique. Ha je ne vais pas pouvoir vous aider monsieur. Désillusion. Je vous conseille d’appeler le bureau de poste le plus proche de chez vous. Donnez-leur le numéro de commande qui figure sur votre courrier. Ils retrouveront le colis et pourront vous dire si le facteur va repasser ou si vous devez aller le chercher. Bien, merci, bonne journée. C’est sûr ça ? Léger stress. Deuxième service support de la journée. Lire la suite « Le Gemba client : une nécessité, épisode 2 »

Le Gemba Client : une nécessité

service-client-operae-partners-lean

Une des pratiques fondamentales du Lean consiste pour l’entreprise à comprendre la valeur de ses produits ou services du point de vue de ses clients. Cette pratique s’apprend sur le terrain, sur le gemba, là où les choses se passent. Pour découvrir ce que les clients attendent, pour comprendre ce qui les fait rêver, il est nécessaire d’aller à leur rencontre.

Dan Jones dans son livre « Le Lean au service du client » explique qu’un produit ou un service rend un client heureux s’il satisfait aux 5 attentes suivantes :

5-attentes-client-lean-operae-partners

Prenons un exemple concret pour illustrer son propos. Allons sur le Gemba.

Disposant d’un nouvel appartement, je souhaite y installer une connexion Internet. En reprenant la grille ci-dessus mes attentes sont les suivantes :

Répondez à toute ma demande :

1 – Je souhaite souscrire à l’abonnement Internet le moins cher.

2 – Je souhaite disposer d’un modem me permettant de me connecter en wifi depuis mon nouvel appartement. Lire la suite « Le Gemba Client : une nécessité »

Bien démarrer un grand programme IT grâce à l’Obeya

principes obeya operae partners

Réussir un programme IT de plusieurs milliers de jours homme est toujours un immense défi. L’expérience nous prouve que l’obeya permet de gérer et de réussir ce type de projet ! Seulement, lancer une obeya dans un tel contexte nécessite un savoir-faire très particulier. Voici le récit d’un retour d’expérience : histoire vraie !

Le lancement d’une Obeya de management se déroule en deux phases :

  1. La préparation
  2. L’atelier

Bien préparer pour réussir

La première phase consiste à collecter toute une série d’informations pour comprendre au mieux la situation à la fois du point de vue des clients, de l’entreprise, des collaborateurs et des partenaires. Il s’agit donc de rencontrer les acteurs clefs du programme afin de :

  1. Cerner les enjeux stratégiques du programme pour l’entreprise et ses clients,
  2. Identifier et de quantifier les attentes des clients,
  3. Se faire une idée concrète du produit,
  4. Collecter les informations de planning et de charge.

Lire la suite « Bien démarrer un grand programme IT grâce à l’Obeya »