Interview

Marie-Pia Ignace, Institut Lean France: «Le Lean réconcilie l’image et le son de l’informatique»

| Mise à jour
par Interview: Rodolphe Koller

Notre rédaction a profité du Lean IT Summit pour échanger avec Marie-Pia Ignace. La Présidente de l’Institut Lean France explique comment l’approche Lean s’applique très concrètement dans les opérations informatiques.

Marie-Pia Ignace est Présidente de l’Institut Lean France et co-auteure de « La pratique du lean management dans l’IT », Pearson, 2012. (Source: Gilles Morelle)
Marie-Pia Ignace est Présidente de l’Institut Lean France et co-auteure de « La pratique du lean management dans l’IT », Pearson, 2012. (Source: Gilles Morelle)

Si vous deviez synthétiser le lean et son apport dans l’informatique…

Le lean est un système dans lequel on veut satisfaire pleinement son client avec un modèle de production juste à temps et une qualité totale. C’est aussi un modèle de management dans lequel les collaborateurs peuvent avoir une réelle autonomie sur des améliorations portant soit sur la vitesse, soit sur la qualité, soit sur la création de valeur pour le client. Le modèle est important pour l’informatique qui doit livrer des projets à temps, dans le budget et avec des utilisateurs qui sont satisfaits. Un idéal, dont on est loin aujourd’hui.

Quels dysfonctionnements observez-vous dans les départements IT ?

Je vois une énorme bureaucratie qui s’est mise en place. Pour des raisons de traçabilité, de validation absolument certaine de tout par tout le monde, on se retrouve avec des réunions et des documents à rédiger à l’infini, et finalement on perd de vue la création de l’objet même. Je vais vous donner un exemple, une entreprise avait un projet nécessitant 25 jours de développement, qui était facturé 100 jours par la SSII et qui nécessitait 400 jours de pilotage en interne. On passe ainsi de 25 à 500 jours parce qu’il faut des validations, des réécritures, du stockage d’information, etc. Les DSI n’ont pas le modèle en tête qu’ont des entreprises qui fabriquent des voitures dans lequel on pousse le produit d’une personne à une autre et où chacun va créer un peu de valeur. Dans l’IT, les choses vont un peu vers l’avant, beaucoup vers l’arrière, parce qu’on va reconsidérer une décision ou que tel formulaire n’a pas été bien rempli, et on va avancer extrêmement lentement de l’idée à la réalisation. La qualité n’est pas non plus au rendez-vous. Il suffit de lire le Chaos Report, plus de la moitié des projets informatiques suivis se soldent par un échec.

Trop souvent aussi, on mesure l’activité et pas ce qui est livré… De ce point de vue, le lean réconcilie l’image et le son. L’image c’est tout va bien, tous les tableaux sont verts ou oranges. Et le son, ce sont des métiers qui râlent et des utilisateurs qui ne sont pas contents. C’est très perturbant pour un DSI. Il voit qu’il y a un écart de perception, mais il ne sait pas où cela se passe.

Pouvez-vous donner des exemples d’améliorations débouchant sur davantage de qualité, d’efficience ou de valeur ?

J’ai par exemple travaillé avec des gens qui font de la gestion d’incidents. Dans le datacenter quand quelque chose se met à clignoter, ils ont des instructions qui les amènent soit à lancer une action, soit à escalader. Pour améliorer les systèmes, les gens commencent par imprimer toutes les fois où ils ont escaladé, alors qu’ils auraient pu résoudre le problème directement. Ils peuvent documenter un cas et aller voir les métiers et leur expliquer comment ils pourraient changer les choses en résolvant ce type d’incidents directement. L’idée étant qu’à chaque fois qu’on escalade on fait courir un risque supplémentaire au client, parce que le temps avance. Et que si on résout directement, on crée davantage de valeur. C’est quelque chose qui est à leur portée et qui permet aux équipes de niveaux 2 et 3 d’être moins sollicitées sur les incidents et plus disponibles pour travailler sur des questions techniques. Autre exemple, une banque voulait réduire les incidents pour réaffecter des gens du helpdesk vers les projets. De fait, si tout fonctionnait bien, on n’aurait même pas besoin de helpdesk... Bref, les équipes du helpdesk ont réalisé, en parlant avec les utilisateurs, qu’ils appelaient en raison d’un message pop-up avec un nom d’erreur indéchiffrable. Le helpdesk était certes capable de les dépanner. Mais les utilisateurs auraient pu résoudre le problème sans le helpdesk, si le message avait dit «Remettez la date au format jour.jour/mois.mois/année.année ». C’est un exemple. Dans une démarche de qualité totale, on se demande ce qui nous a pris de travailler de cette façon et de générer un tel message. Et, petit à petit, on détruit l’origine des défauts.

Comment l’approche lean s’articule-t-elle avec le thème en vogue de «transformation digitale»?

Je vois trois domaines dans lesquels les DSI doivent gagner en crédibilité face à l’enjeu de la transformation digitale. Le premier concerne la disponibilité des applications. Google ou Amazon ne tombent jamais en panne: les DSI ne savent pas gérer ce niveau d’exigence. Le lean permet d’aborder le sujet sous forme d’écart de performance avec un savoir interne à construire pour le combler. Donc ce que je fais, ce sur quoi je me bats, les mesures que je prends au niveau de mon architecture, de mon datacenter, pour arriver à 99,9%, puis à 99,99% de disponibilité. Le second domaine est la commoditisation, ou comment je fais en sorte qu’un certain nombre de choses en informatique deviennent aussi simples que d’appuyer sur un bouton pour allumer une ampoule. Vous avez des équipes digitales brillantes et innovantes; vous les asseyez à un poste de travail dans une grande entreprise et vous leur dites «Allez-y !». Au moment où ils souhaitent accéder à une donnée, il leur faut remplir un formulaire qui part dans un workflow, qui arrive dans un stock, si bien qu’au final ils n’obtiennent l’accès que trois semaines plus tard... Les gens se découragent et, bien souvent, ils partent.  Dans ce monde du digital, ce que l’on veut c’est pouvoir aller de l’idée à la création de l’objet. Vous commencez à coder, vous commencez à tester, à avoir un peu de feedback, à améliorer le système. La capacité à faire les choses très vite est extrêmement importante et le lean peut aider le DSI à accélérer. Enfin, un troisième domaine est la création de valeur. Comment est-ce que j’arrête d’imaginer que la valeur se crée de façon habituelle et comment je commence à utiliser le feedback des utilisateurs. Je les regarde travailler, je fais des test, je change des choses, je regarde si les choses vont un peu mieux qu’avant.

Où situez-vous lean par rapport à Agile?

Nous connaissons bien la communauté Agile et nous avons exploré ce qui nous réunit. Nous nous ressemblons notamment dans la notion de petits lots. Dans le lean on ne construit pas un énorme objet, mais on construit mille fois un petit objet. Nous nous ressemblons aussi dans l’importance donnée au client. Mais nous avons aussi des différences et des complémentarités. Agile est un système pour construire des choses, tandis que le lean est un système pour réfléchir à ce que l’on fait. Les agilistes s’attachent par exemple à livrer un certain nombre de points fonctionnels dans les temps et à réorganiser le travail pour atteindre cet objectif. Dans le lean, vous analysez chaque difficulté, chaque écart que vous rencontrez en chemin: ici un bug qui a augmenté les coûts, là une description imprécise qui a fait perdre du temps. Le lean apporte aux agilistes un moteur pour l’amélioration.
 

Webcode
7987

Kommentare

« Plus