Le 8 décembre 2009, DSI et experts sont venus échanger sur le Lean et sa déclinaison aux systèmes d’information, à l’occasion d’une conférence-débat organisée par Best Practices Systèmes d’Information, en partenariat avec Fujitsu. Les différents témoignages présentés à cette occasion traduisent à la fois l’intérêt des DSI pour cette démarche et leurs interrogations, nombreuses.
Comment appliquer les principes de création de valeur du Lean à la gestion des systèmes d’information ? Si la démarche, historiquement mise au point chez Toyota, est connue depuis longtemps dans l’industrie, elle apparaît relativement nouvelle pour les directions des systèmes d’information.
Le Lean IT est souvent abordé sous l’angle de l’amélioration continue, notion avec laquelle bon nombre de DSI sont déjà familiarisés. Interrogés sur les apports du Lean dans ce type d’approche, les DSI réunis par Best Practices ont souligné l’une des difficultés des démarches d’amélioration continue : trouver les bonnes métriques pour mesurer cette amélioration. Ainsi, le DSI d’un groupe logistique a pu observer que, d’après son expérience, les métriques associées aux processus sont souvent insuffisantes.
« Qui dit Lean et Six Sigma suppose d’avoir des processus structurés, ce qui n’est pas toujours le cas, précise-t-il. Nous avons une démarche d’amélioration. Mais une démarche d’amélioration mesurée avec des méthodes managées ? Beaucoup moins. » Un autre participant, DSI d’une entreprise industrielle, a présenté la question ainsi à son responsable qualité. « Mesurer l’avancement du processus n’est pas la question, s’est-il vu répondre. La vraie question concerne la satisfaction des clients. Il faut définir qui ils sont et ce qu’ils attendent. »
Rebondissant sur cette remarque, le premier intervenant s’est interrogé : « Même si l’on demande chaque année aux clients leur degré de satisfaction, comment s’assurer en cours de route que l’on s’oriente dans la bonne direction ? »
Gilles Siméon, consultant chez Fujitsu, est revenu sur la notion de métriques dans le Lean, expliquant que celles-ci s’appliquent à trois aspects : le taux de non-qualité, le temps à valeur ajoutée et le temps à non-valeur ajoutée. « Le travail effectif est souvent difficile à mesurer, mais il est possible de regarder combien de temps prend chaque tâche en choisissant un processus clair, par exemple le traitement de bout en bout d’un dossier par le help-desk. Ensuite, il suffit, tout simplement, de chronométrer les différentes tâches. »
Le consultant a également souligné l’importance d’une cartographie de la chaîne de valeur (Value Stream Mapping), qui permet d’identifier où interviennent les gaspillages et où placer les indicateurs de mesure.
Cette approche, née dans l’industrie, est-elle applicable quel que soit le secteur d’activité, en particulier dans les services? Paul Gette, également consultant chez Fujitsu, a répondu par l’affirmative, s’appuyant pour cela sur le projet qu’il mène actuellement dans une grande banque française. « Nous venons de faire une cartographie de l’existant avec les différents acteurs du processus.
La réalité colle rarement avec ce qui est mis par écrit dans les manuels. Une fois cette étape franchie, nous pouvons réfléchir aux différentes façons d’améliorer le processus. » Un autre intervenant, DSI dans le secteur des services, a lui aussi initié une démarche d’amélioration des processus centrée sur les échanges interentreprises : « Les flux concernés passent par une multitude de supports : machines, personnes, systèmes d’information. Faire une cartographie reste extrêmement complexe. Par ailleurs, le chronomètre surprend un peu. »
Un bouleversement des missions des managers
Le responsable des méthodes d’un groupe de crédit a lui aussi partagé son expérience. « Nous avons engagé une démarche de Lean il y a quelques mois au sein de la DSI. Un des principaux changements concerne le rôle du manager. Celui-ci n’est plus chef mais animateur, il est là non pas pour prendre des décisions mais pour aider ses collaborateurs à en prendre. »
Autre changement : « Il ne s’agit plus seulement d’interroger les clients pour savoir si le produit leur convient, il faut aller plus loin en identifiant les actions à valeur ajoutée, celles pour lesquelles le client est prêt à payer. » Mais cela fait naître des difficultés de disponibilité. « Immobiliser pendant une journée complète des acteurs de la hot-line si l’on travaille sur la gestion des incidents reste compliqué. » En revanche, cela permet aux équipes de se poser les questions différemment, de raisonner moins en termes de moyens de traitement mais davantage sur le taux de respect des contrats de services.
« Le Lean, c’est d’abord de la gestion du changement, c’est en cela que la démarche n’est pas simple, a souligné ce responsable des méthodes. Nous sommes cependant convaincus de son efficacité, y compris dans une DSI. » Un de ses homologues d’une grande banque s’est engagé dans une démarche similaire, centrée à la fois sur les métiers bancaires et l’informatique de production. « Nous avons mené un programme sur deux ans. Nous avons d’abord travaillé sur ce qui nous semblait le plus simple, c’est-à-dire le maintien des conditions opérationnelles.
Dans un deuxième temps, nous avons travaillé sur la partie projets. » Lors de cette deuxième étape, le groupe bancaire a appliqué la méthode Design For Six Sigma (DFSS). « Au lieu d’améliorer un processus existant, l’idée est de partir de la connaissance qu’on en a et de construire le processus tel qu’il devrait être. » Cette partie s’est avérée nettement plus complexe. « Six Sigma s’appuie sur les processus. Quand ceux-ci sont juste décrits dans des manuels inutilisés, les acteurs n’en ont pas conscience. » La première action à entreprendre consiste donc à mobiliser les individus sur les processus.
« Il faut qu’ils prennent bien conscience que les processus dont on parle ne sont pas des processus théoriques mais leurs propres processus », a souligné le coordinateur des systèmes d’information de ce groupe bancaire. La vraie difficulté, selon lui, a été d’amener les collaborateurs au changement. En effet, dans le cadre d’un projet Lean, les équipes opérationnelles doivent passer d’un mode où cela fonctionne bien à un mode où on leur dit : « Cela pourrait fonctionner mieux. »
Il faut ainsi parvenir à leur prouver que la méthode et les changements proposés vont être utiles non seulement pour le management, mais aussi pour eux, en termes de fluidité et de confort. Pour le responsable des services partagés de ce groupe bancaire, le Lean implique une culture d’excellence opérationnelle. Les premiers résultats du projet ont montré une réduction des coûts d’environ 20 %.
En revanche, l’entreprise a eu plus de mal à évaluer les gains non financiers, tels que l’amélioration du fonctionnement des processus ciblés : « Aujourd’hui, nous n’avons pas encore la réponse », avoue-t-il. Les responsables du projet déplorent également un manque de dynamisme sur la conduite du changement, constatant que certains des efforts qui ont permis ces gains sont difficiles à maintenir dans la durée.
Réagissant à ces témoignages, Gilles Siméon a souligné deux points auxquels prêter particulièrement attention.
Tout d’abord, la personne impliquée dans un processus ne doit pas considérer uniquement la partie dans laquelle elle intervient, mais elle doit voir la performance du processus dans sa globalité : « C’est tout le contraire du fonctionnement en silos. » Autre aspect important : le management par les objectifs. « On ne peut pas demander à quelqu’un d’être performant sans lui donner des objectifs, poursuit Gilles Siméon.
Toute la difficulté, c’est de trouver les bons objectifs, de faire correspondre les objectifs de l’entreprise avec les objectifs quotidiens des opérationnels. » Il faut définir ensemble des objectifs clairs et atteignables pour motiver les acteurs et les amener à se poser des questions sur l’amélioration continue.
Dans l’industrie, le Lean est une notion connue depuis longtemps au niveau des unités de production. Son application à l’IT n’en soulève pas moins de nombreuses questions. Le DSI d’un laboratoire pharmaceutique, qui a engagé une réflexion sur le Lean, s’interroge par exemple sur les processus à cibler en priorité dans une logique de « quick win » (gain rapide) : « Par où commencer pour pouvoir démontrer rapidement de la valeur ? », s’est-il demandé.
En réponse, Paul Gette a souligné l’importance d’identifier les problématiques réelles du client : « Il faut identifier un problème, si possible transversal dans l’organisation, dont les conséquences justifient qu’on le traite, dont la résolution est porteuse de promesses et dont les effets seront perçus dans toute l’entreprise. »
Pour le DSI d’un groupe métallurgique, les aspects systèmes d’information peuvent intervenir dans des démarches Lean plus globales. « Nous avons pour objectif d’arrêter le moins possible nos fours de fusion, qui sont au cœur de notre activité. Pour cela, il est essentiel d’avoir une informatique industrielle hautement disponible. Nous menons également une démarche de Lean appliquée à nos processus d’approvisionnement. Il est intéressant que la DSI soit impliquée dans cette démarche, en particulier pour le choix d’outils de gestion de la chaîne logistique. »
Identifier les bons leviers
Le DSI d’un fabricant d’équipements de loisirs a expliqué que lors de sa prise de fonction, il a souhaité entamer une démarche Lean mais s’est heurté à la même difficulté que son homologue d’un laboratoire pharmaceutique : l’identification des leviers appropriés pour l’informatique.
Un participant a mis en exergue l’intérêt d’une cartographie de type « Value Stream Mapping » pour répondre à ce type de questionnement. Cette cartographie, qui détaille les étapes de transformation d’un service, aide à identifier les temps qui génèrent vraiment de la valeur par rapport au client final. Le DSI d’une entreprise de services a expliqué qu’il était assez aisé de mener ce type d’analyse sur des tâches récurrentes de type help-desk, mais qu’il reste néanmoins difficile d’appliquer à l’informatique des mécanismes issus de l’industrie.
« La problématique, lorsque l’on atteint 97 % ou plus de qualité de service, est d’identifier l’élément différenciateur qui va apporter de la valeur », a pointé la responsable production d’une grande entreprise de services. En chronométrant les analystes qui effectuaient des tests, elle a réussi à identifier le retour sur investissement possible en automatisant certaines étapes.
La discussion a ensuite porté sur la question de la maturité de la démarche Lean IT. Il convient de distinguer le Lean appliqué au développement de celui appliqué à la production. Du côté du développement, il existe une certaine confusion sur le terrain avec les méthodes agiles, dont l’un des objectifs est également d’éviter le gaspillage de temps. Côté production, en revanche, le terrain semble encore relativement vierge.
Le Lean s’applique assez facilement à des services de type help-desk ou IMAC (Installation, Move, Add, Change) parce que ceux-ci sont bien identifiés. Le stade suivant concerne la consolidation et la rationalisation du système d’information à travers des techniques de type 5S (technique pour maintenir des environnements de travail propres).
Il s’agit, par exemple, de réfléchir à la manière de placer les applications sur les serveurs selon les performances requises ou l’utilisation prévue. L’application de techniques de l’industrie comme SMED (Single Minute Exchange of Die, remplacement d’une pièce en une minute) afin de réduire au maximum les interruptions sur le système d’information est un autre axe de réflexion.
Illustrant ce point, un DSI a expliqué que, lorsque ses équipes constataient un problème nécessitant l’interruption d’un processus métier, elles en profitaient pour regarder aussi tout ce qui pouvait être amélioré afin de minimiser les interruptions.
Quelle complémentarité avec Itil ?
Un autre aspect important des problématiques Lean est de traduire les besoins des clients en critères assimilables par la production informatique. Itil V3 commence à s’intéresser à ces aspects, notamment avec l’apparition d’un processus de capture des besoins du client. Toutefois, le lien entre Itil et Lean IT n’est pas si étroit.
Itil concerne les processus, tandis que le Lean IT concerne la performance des équipes. La différence porte notamment sur les indicateurs suivis : la performance d’une équipe n’est pas la performance du processus, mais il faut, quand même, fixer des objectifs aux équipes, non aux processus. Il s’agit bien de deux types d’objectifs différents, à ne pas assimiler. Itil travaille sur la robustesse et les SLA (engagements de services), tandis que le Lean travaille sur l’efficacité.
Les deux approches sont complémentaires. Itil est un ensemble de bonnes pratiques qui fournissent un cadre pour la production. Ce cadre peut encore être amélioré une fois mis en place. L’une des premières cibles pour le Lean est l’amélioration des processus Itil.
Philippe Tassin, DSI de transition, est revenu sur une difficulté évoquée à plusieurs reprises par les participants : le chronométrage des tâches, souvent source de blocage mais pourtant indispensable pour disséquer les processus. « Cela fait très longtemps que cela existe dans l’industrie et ce principe est accepté par les opérateurs qui se font chronométrer !
Il n’y a aucune raison qu’il ne soit pas accepté par des équipes informatiques. Je ne dis pas que chaque ingénieur en conception doit s’équiper d’un chronomètre. Par contre, pour des collaborateurs qui réalisent des opérations plutôt répétitives, par exemple pour les équipes de production ou de support, cela se justifie. Que ce soit difficile, je n’en disconviens pas… Je crois que la DSI arrive à une phase où elle doit absolument s’industrialiser. Cependant, avant de songer à s’améliorer, il faut s’assurer de la robustesse du système d’information, c’est un principe de base fondamental. »