Voici en quels termes, Benoit, collaborateur du dernier projet Lean que j’ai animé dans la DSI d’un grand groupe témoigne :

« Au front-end daily, on a régulièrement des discussions avec des personnes du back-end pour par exemple vérifier le statut des comptes. Pour ce faire, je suis en contact avec Sven, certains jours, jusqu’à 5 à 6 fois par mail. »

Jusqu’au jour où le coach m’a posé une question : « Sais-tu où se trouve Sven ? »

Moi : « Euh… non pas du tout ! »

Le coach : « As-tu déjà regardé dans l’annuaire interne ? »

Vérification faite, je découvre que Sven travaille au même étage dans le même bâtiment que moi. Je décide avec le coach de partir à sa recherche…

En moins de 2 minutes, nous l’avions trouvé. « On se dit bonjour tous les matins, son bureau se trouve de l’autre côté de l’armoire. Grâce au Lean, j’ai découvert des collègues à moins de 10 mètres ! ».

Ce témoignage peut donner à sourire… Il n’est certes pas représentatif de l’apport de la démarche Lean au sein d’une équipe. Mais il est malheureusement symptomatique d’une dérive de la plupart des DSI des grands groupes : des personnes qui travaillent ensemble sur un même applicatif ne se connaissent pas.

Comment en est-on arrivé là ?

Les déménagements successifs des équipes suite aux nombreuses réorganisations ? Les changements réguliers de consultants, au gré des négociations de la direction des Achats ? La mise en place des politiques de télétravail ou de « flex-office » ?

En fait, nombre de DSI cherchent à optimiser le coût des processus de développement en le divisant en activités élémentaires afin d’optimiser chacune d’elles séparément. Mais c’est impossible… Quand elles optimisent les coûts de développement en obligeant les sous-traitants à baisser constamment leurs prix, les équipes de tests reçoivent des codes avec tellement d’anomalies que les coûts et les délais de production augmentent à cause des corrections.

Non seulement, cette politique de découpage ne permet pas d’optimiser les coûts de développement mais en plus elle est souvent très néfaste pour la cohésion des équipes. Elle a, a minima, pour effet de créer des silos en complexifiant les échanges entre les équipes, mais elle peut même aller jusqu’à générer de la concurrence entre les équipes lorsqu’une partie du travail est enlevée à certains pour être confiée à un sous-traitant externe.

Dans son livre « Out of the Crisis » publié en 1982, Edward DEMING, condamne cette approche chez les industriels américains qui, dans leur majorité, restent des adeptes inconditionnels des principes de la division du travail prônés par Henry FORD. A l’inverse, E. DEMING préconise lui d’abattre les barrières entre les départements. Le travail en équipe de toute l’entreprise permet de prévoir les problèmes qui peuvent apparaître au cours de la réalisation et de l’utilisation des produits.

Cette approche exige que le cadre dirigeant étudie le système humain dont il est responsable. Il doit faire en sorte que les individus et les équipes travaillent ensemble en fonction d’un but bien défini et que chacun comprenne comment son travail s’accorde avec celui des autres. Dans ces conditions, les salariés sont plus heureux et les résultats de l’entreprise s’améliorent

La politique de l’entreprise doit être de développer la connaissance dans un climat de coopération.

Les équipes de conception doivent travailler avec les développeurs afin d’éviter de concevoir des « usines à gaz » impossibles à maintenir. Les développeurs doivent rencontrer les équipes de production pour concevoir des procédures d’installation optimales. Le but est de faire en sorte que tout le monde soit gagnant.

Il n’est pas surprenant que DEMING, fut pendant longtemps le conseiller le plus apprécié des grands patrons japonais.