Techniques de l’Ingénieur : 2010 est une année spéciale pour le Midest…

Sylvie Foum : Il est vrai que le Midest fête sa quarantième année en 2010. Derrière ces quarante ans il y a l’histoire d’une naissance, mais c’est aussi toute l’histoire d’une évolution, très corrélée bien sûr à celle de l’industrie.

Parlez-nous du Midest.

Le Midest est le salon de la sous-traitance industrielle au sens large. Nous recouvrons tous les secteurs de la sous-traitance, à l’acception du bois et du textile. Ainsi, nous traitons de la transformation des métaux sous toutes ses formes, nous traitons aussi les plastiques et les caoutchoucs. Le Midest s’adresse également à des secteurs beaucoup plus spécifiques, comme les microtechniques, les fixations industrielles, traitement des matériaux et de surface…

Qu’est-ce qui fait la particularité du salon ?

Le salon est né en 1971 à Nancy. Cela correspond à une époque où l’industrie était assez puissante, mais où la nécessité d’élargir le spectre de rencontre entre des industriels nationaux et des opérateurs travaillant pour eux se faisait d’ors et déjà sentir. Aujourd’hui, nous réunissons les industriels qui travaillent pour le compte de donneurs d’ordres et les mettons en relation avec ces donneurs d’ordre. Avec la crise, le salon revêt aujourd’hui une importance particulière, pour les exposants qui réduisent leurs démarches de communication. L’avantage du Midest est qu’il est leader sur son secteur. Ainsi, les entreprises de la sous-traitance, même pendant la crise, sont restées fidèles au salon.

Dans un monde globalisé, quelles sont aujourd’hui les raisons d’être du salon ?

L’objectif du Midest, dans le cadre d’un marché très mondialisé, est de réunir le « best of » des savoirs-faire mondiaux. Nous sommes donc très ouverts à l’international, avec plus de 40 % d’exposants étrangers : Chine, Inde, Singapour, Taïwan, tous les pays d’Europe de l’Est, le Magrheb… Seul le marché américain n’est pas très représenté, car ce dernier a tendance à tourner sur lui-même.

L’industrie de la sous-traitance a beaucoup évolué en France ces quarante dernières années ?

Une des grandes tendances qui s’est manifestée tout au long de l’existence du Midest, c’est bien la mondialisation du marché. Il y avait 137 exposants au premier Midest, presque tous français. Aujourd’hui, la mondialisation des échanges se ressent au niveau des différentes nationalités qui exposent ici. Ce qu’on peut dire, c’est que depuis quarante ans, l’industrie française a beaucoup souffert. Beaucoup d’entreprises sont mortes, notamment ces dernières années.

Quelles sont les grandes tendances du salon cette année ?

Les grandes tendances de cette année vont soit vers des entreprises de plus en plus spécialisées, soit des entreprises qui se sont diversifiées pour aller sur les nouveaux marchés : environnement, énergie, luxe, médical.
Il y a eu une concentration des acteurs sur le marché, avec beaucoup d’entreprises qui ont disparu dans cet intervalle. La crise de 2009 a encore accéléré ces grandes tendances.

Quels sont les enjeux futurs pour les entreprises qui viennent sur le salon cette année ?

Tout d’abord, dans le contexte actuel, il s’agit pour ces entreprises de se restructurer sur leurs fondamentaux. Par exemple,aujourd’hui, ne pas avoir un outils de production qui n’est pas en phase avec les commandes semble être une nécessité absolue. Pour ces entreprises, investir beaucoup dans les technologies et les outils de production, au niveau de leur informatisation, est un facteur de croissance énorme, qui peut également leur permettre de se mettre en relation avec de nouveaux clients.

Quels sont les recommandations actuelles pour les entreprises françaises de la sous-traitance ?

Il faut investir dans une industrie puissante, dans de la formation qualifiée, et continuer à travailler sur les grands axes d’aujourd’hui, notamment au niveau du changement des mentalités. Nos clients nous font remonter que la crise a permis aux donneurs d’ordre de comprendre l’importance de la sous-traitance, et cela est très positif. On sent une dynamique plutôt positive dans l’ensemble.

Techniques de l’Ingénieur : Quelle est la position de la France sur le marché mondial de la sous-traitance ?

Sylvie Foum : Aujourd’hui en France, 25 % de la production est destinée à des clients étrangers, tandis que notre pays importe le quart des ses besoins de l’étranger. En 2009, la chute du marché de la sous-traitance européenne a été estimée à 25 %. Ce chiffre est de 22 % en ce qui concerne directement le France, en termes de chiffre d’affaires. Il y a donc des conséquences en termes d’emploi, mais aussi en termes de perte de savoir faire.

Quelle a été l’impact de la crise sur les entreprises françaises de la sous-traitance ?

On estime que 1800 entreprises de sous-traitance ont disparu à cause de la crise de 2009. Celles qui restent sont soit celles qui ont réussi à prendre la vague de l’innovation, soit la vague de l’internationalisation. Celles qui ont choisi l’innovation ont su développer des savoirs faire, souvent en coopération avec leurs clients, et se sont mises sur des créneaux de spécialisation qui les ont rendu compétitives et partenaires avec leurs clients. Les entreprises qui ont choisi l’internationalisation sont allés implanter des filiales dans les pays émergents, ou alors ont accompagnés leurs clients qui eux-mêmes ont délocalisé leurs usines.

Comment ont fait ces entreprises pour éviter le naufrage en 2009 ?

Celles qui ont résisté sortent plus aguerries de la crise. Celles qui ont résisté sont celles qui se sont concentrés sur leurs fondamentaux. Ces entreprises ont épuisé toutes les solutions en termes de chômage partiel, technique. Ces entreprises qui ont su résister à ça sont aujourd’hui en ordre de marche, et sont là au Midest. Ce sont avec ces entreprises que l’on regarde vers l’avenir.

Les relations entre les donneurs d’ordre et les sous-traitants ont elles évolué depuis cet épisode ?

Il faut absolument que la sous-traitance arrive à travailler de manière partenariale avec les donneurs d’ordre. C’est un enjeu fondamental pour l’Avenir de la sous-traitance : il faut qu’il y ait une reconsidération de la relation entre les « donneurs d’ordre » et les « preneurs d’ordre », car cela a toujours constitué un problème en France. Mais les choses semblent aller dans le bon sens. La crise a montré qu’une coopération plus étroite en tre les donneurs d’ordres et les entreprises de la sous-traitance permettaient aux acteurs de travailler plus efficacement et de mieux gérer les moments plus difficiles.

La problématique énergétique touche toute l’industrie. Comment s’illustre t-elle au niveau des industriels de la sous-traitance ?

Les sous-traitants sont très concernés par ça, de manière directe et indirecte. Plus vous êtes une PME, plus vous ressentez la pression due à l’environnement et à l’énergie comme une sanction. Vu le prix de la matière première dans les usines, ce sont aussi les premiers à être concernés par cette révolution. Beaucoup d’entreprises en profitent pour réaliser des économie. Cela nécessite de la formation, de l’information. Cela coûte de l’argent au départ également, de faire appel à des compétences extérieures, mais le résultat est souvent positif. La deuxième chose, pour l’industriel, c’est la nécessité d’être aux normes, pour pouvoir respecter les cahiers des charges imposés par les donneurs d’ordre. Nous envisageons l’année prochaine de créer un espace dédié, en collaboration avec l’Admet, pour marquer l’impact des problématiques environnemental.

Comment les progrès des TIC influencent-ils le marché de la sous-traitance ?

Les TIC ont pris une importance considérable, à deux niveaux : on a une plus grande ouverture du marché, grâce au sourcing par internet. Il s’agit déjà d’une donnée fondamentale. Ensuite, les progrès informatiques permettent aussi des applications de plus en plus informatisées, monitorisées. Aujourd’hui, un sous-traitant doit absolument s’informatiser pour pouvoir travailler avec des clients sur des développements de nouveaux produits. L’informatisation est également un facteur important à plus long terme pour la sous-traitance, pour pouvoir travailler en anticipation sur les cahiers da charges clients.

Techniques de l’Ingénieur : La transversalité des processus n’est-elle pas le point fondamental de toute réflexion Lean ?

Philippe Crart : Le concept du Lean est, à mon avis, indissociable de la notion de transversalité des processus. Dans mon premier métier qu’est le consulting en organisation industrielle, je privilégie l’approche de raisonner non pas suivant la structure verticale de l’entreprise, mais plutôt selon la transversalité des processus. Depuis une dizaine d’années, celle-ci constitue l’approche de l’ISO 9000, et aujourd’hui, elle est envisagée dans toute démarche Lean. Cela dit, il convient de rappeler que le processus le plus classique sur lequel on a commencé à appliquer la philosophie Lean et ses approches, est celui des métiers du Manufacturing, dans la mesure où il y a un flux physique. Dans le « lean manufacturing », on s’intéresse à ce flux, à sa valeur ajoutée, en cherchant à éliminer les dysfonctionnements et les gaspillages.

Le travail porte donc uniquement sur les flux physiques ?



Il me semble qu’il n’y a aucune raison pour justifier l’exclusion des autres flux au niveau de l’application de cette philosophie. Par autres flux, je fais allusion aux flux d’informations sur le management de la qualité et son contrôle, par exemple. Il est également légitime de se demander pourquoi ne pas l’appliquer à d’autres processus tels que celui de la direction générale. Nul ne peut nier qu’une direction générale est payée pour prendre des décisions. C’est là où elle crée de la valeur. On peut donc analyser de la même manière les dysfonctionnements du processus de décision d’une direction générale et l’aider à améliorer ce processus et à rendre les décisions plus pertinentes, plus rapides et mieux ciblées sur la stratégie.

Parlez nous des interfaces entre les processus ?



En travaillant sur le Lean, j’ai découvert l’existence d’interfaces entre les processus, et je me suis également rendu compte qu’il y avait les mêmes gaspillages, pertes d’énergie et dysfonctionnements dans ces interfaces qu’à l’intérieur d’un processus. Progressivement, on est arrivé à définir un concept qu’on appelle « lean integration », et qui consiste à appliquer les principes du Lean non plus à un processus, mais à un ensemble de processus interconnectés. Cela a l’avantage d’amener une équipe à s’intéresser aux interfaces entre les différents processus dont elle a la responsabilité.


 

Pourriez-vous illustrer ce concept par un cas pratique?

L’exemple qui illustre bien ce concept est celui d’une entreprise qui opère dans l’industrie pharmaceutique. Cette entreprise m’a demandé de réduire son cycle de production de 40 % en six mois, ce qui revient à un passage de 53 à 33 jours dans la production de ses médicaments.

Comme vous le savez, l’industrie pharmaceutique est une industrie où le processus industriel, c’est-à-dire la décomposition des opérations qui permettent la fabrication du médicament, leur enchaînement et les techniques employées pour la fabrication, est bien défini et décomposé en un ensemble cohérent d’opérations liées. Il s’agit donc de les corréler et d’étudier, au cas par cas, les possibilités en termes de gain de temps et d’énergie.
 

À l’heure où la plupart des projets transverses sont repoussés faute de moyens pour les financer, il en est un qui arrive souvent à rester en haut de la pile : le Lean. Compte tenu de notre approche orientée sur les réalités concrètes de nos clients, ce point de vue ne cherche pas à être le manuel de référence du Lean Management mais plutôt à remettre en perspective ce concept, compte tenu de son histoire et de ses mises en pratique, et ainsi apporter des réponses aux questions telles que : Pourquoi en parler aujourd’hui ? Concrètement, qu’est-ce-que c’est ? Comment le mettre en oeuvre ?
Il est possible d’appréhender le Lean Management comme le moyen de réduire le « poids » d’une organisation et ainsi la rendre plus manœuvrable, et donc finalement lui permettre de s’ajuster plus rapidement en cas de changements de contexte.

Historiquement, le Lean est le nom donné par des chercheurs du MIT au système de production mis en place dans les usines Toyota après la guerre. Mis en place sous forme d’exercice auquel participait chacun des ouvriers, il s’agissait pour ces derniers de participer la réflexion menée dans l’entreprise sur les économies de coûts, d’énergie et de matière.

Aujourd’hui, les entreprises ou directions faisant face à des réductions budgétaires, alors que leur structure et leurs investissements passés consomment obligatoirement une part importante de ces budgets, voient facilement l’intérêt de changer leurs méthodes de travail. Le « régime » Lean Management fait la chasse aux activités sans valeur ajoutée. Cet objectif directeur permet d’identifier cinq principes :

• définir la valeur ;
• identifier la chaîne de valeur ;
• obtenir un flux continu ;
• tirer la production ;
• viser la perfection.

Ces différents objectifs cherchent à identifier, puis éliminer, les pertes générées par une organisation et des process non optimisés. Cette suppression des pertes conduit naturellement à la fluidification de la production et donc à une meilleure maniabilité, objectif permanent de tout dirigeant. D’abord conceptualisé dans le monde industriel, la réflexion sur le Lean Management s’est ensuite portée sur son application dans le domaine des systèmes d’information au début des années 2000.

Le monde industriel, caractérisé par l’importance de ses chaînes de production, est naturellement focalisé sur des objectifs de réduction des temps de production, de réduction des défauts de fabrication, d’optimisation de planification… Comment le Lean va t-il trouver une pertinence à travers tous ces objectifs à priori plutôt hétérogènes ?

Compte tenu des changements induits par ces méthodes dans le travail quotidien, autant d’un point de vue pratique que d’un point de vue état d’esprit, leur mise en oeuvre ne peut se faire efficacement que de manière unitaire.
Le « tout, tout de suite » est à proscrire et une vrai réflexion sur le cadencement des mises en oeuvre doit être menée. En fait, le Lean management doit plus être appréhendé comme une philosophie et un ensemble de bonnes pratiques plutôt qu’un système à part entière. D’ailleurs, l’application du Lean tel quel en tant que système à part entière conduit généralement à l’échec de sa mise en place effective.

L’objectif : coordonner les différentes méthodes Lean dans une démarche générale d’amélioration

Il est intéressant pour cette réflexion de partir du cycle de vie d’un process dans lequel on distinguera trois phases principales : la création, l’évolution (avec des besoins de mesure, d’analyse, d’amélioration, de contrôle) et enfin la rupture. Pour chacune de ces phases, il est possible d’identifier les méthodes les plus pertinentes. Par exemple, dans une phase de création, il est possible de partir d’une formalisation de la chaîne de valeur pour construire le « workflow » correspondant. L’intérêt de ce « mapping » est de savoir quelles méthodes sont envisageables compte tenu de la maturité du process. Il est possible également d’engager en parallèle des démarches différentes dans des secteurs différents de l’entreprise. Les expériences faites sur un secteur ou process pouvant ensuite servir d’exemple aux autres secteurs lorsqu’ils atteignent le niveau de maturité adéquat.

Ainsi, sans établir de règles strictes pour mlener à bien la mise en place du Lean dans une entreprise, on peut tout de même lister les quatorze principes qui accompagnent une démarche Lean, quelle que soit l’activité de l’entreprise concernée. Les 14 principes sont :

• Baser la prise de décisions sur une philosophie à long terme, en acceptant les conséquences financières à court terme ;
• Créer des processus qui permettent de mettre les problèmes en évidence rapidement (flux continu) ;
• Utiliser le « flux tiré » pour éviter la surproduction ;
• Lisser la production ;
• Intégrer à la culture la nécessité d’arrêter la production dès l’émergence d’un problème de façon à produire de la qualité du premier coup ;
• La standardisation du travail est la base de l’amélioration continue et de l’implication des collaborateurs ;
• Utiliser le management visuel afin qu’aucun problème ne soit caché ;
• Ne mettre au service du personnel et des processus de production que des technologies éprouvées ;
• Former des leaders qui connaissent parfaitement le travail, et qui incarnent la philosophie ;
• Développer des collaborateurs et des équipes de travail exceptionnels qui embrassent la philosophie de l’organisation ;
• Respecter son réseau étendu de partenaires et de fournisseurs en les encourageant et les aidant à s’améliorer ;
• Aller soi-même sur le terrain, pour comprendre en profondeur la situation ;
• Prendre les décisions lentement, par consensus, en considérant toutes les options possibles ;
• Mettre rapidement en place les solutions choisies ;
• Devenir une organisation qui apprend à travers la réflexion au fil de l ’eau et l’amélioration continue.

L’arrivée du Lean Management dans les SI s’est fait par le biais des méthodes agiles. Les principales évolutions récentes en termes de gestion de projet IT ont tourné autour de la mise en œuvre de méthodes dites agiles : l’objectif de ces méthodes est de répondre au réel besoin des utilisateurs en les impliquant plus fortement et en assurant une réactivité forte par rapport à leurs demandes. Ainsi, cette approche contraste avec par exemple un projet sur une durée de plusieurs mois, initié sur la base d’un cahier des charges, qui conduit nécessairement à un écart entre le résultat livré et l’attente de l’utilisateur.

L’écart provenant notamment de deux éléments : un cahier des charges qui ne réussit pas à formaliser les besoins réels, et des besoins qui évoluent avec le temps. Deux leçons principales sont à retirer de ce constat : le besoin d’interaction avec l’utilisateur pour pouvoir discuter et challenger son besoin, et le besoin d’adaptabilité pour pouvoir prendre en compte les évolutions. En réalité, il existe encore peu d’applications du Lean Management dans le SI. Les rares approches dans le monde des SI se sont faites en majorité sur la partie développements, mais Il existe encore peu d’exemples d’application du Lean au niveau d’une Direction des Systèmes d’Information. Les cas significatifs et visibles sont donc plus à rechercher du côté des entreprises purement IT.

Un exemple frappant est la percée réalisée par Google qui a su mettre en place à la fin des années 90 un moteur de recherche focalisé sur la pertinence et la rapidité des résultats (mettant par exemple de côté toute recherche de graphisme attractif). C’est un très bon exemple. En fait, il s’agit de penser la DSI comme une entreprise et appliquer à son organisation et ses processus les méthodes d’optimisation éprouvées dans le monde industriel. Pour plus facilement définir comment transposer des méthodes du monde industriel vers les systèmes d’information, il convient de reconsidérer la Direction des Systèmes d’Information comme une entreprise à part entière, fournissant des produits et services à ses clients avec des contraintes de gestion et d’administration (budget, ressources humaines…).

Il est alors impératif :

• de clairement identifier les produits et services fournis (notion de catalogue de services) et de définir les niveaux de services attendus avec les utilisateurs (notion de SLA) pour dimensionner au juste besoin ;
• d’identifier les différents process et de les mapper avec une cartographie fonctionnelle du métier du client, pour savoir en évaluer les enjeux respectifs ;
• de définir la chaîne de création de valeurs sur ces process pour identifier les optimisations possibles.

Bien sûr, toues ces actions doivent être entreprises en anticipant les impacts et le niveau de rigidité induits par tout changement sur l’organisation.

Certaines démarches d’amélioration peuvent être « repensées Lean »

Ainsi, les points cités ci-dessous sont quelques exemples de l’approche proposée par les cabinets de conseil en stratégie des Systèmes d’informations et intégrée dans leurs offres, au-delà de sujets plus évidents tels que des démarches d’organisation de la fonction informatique ou d’efficacité des processus.

Voici les points principaux de ces offres :

• Évaluer le poids d’une structure comme indicateur de performance : Pour la création ou la mise à jour de tableaux de bord, des gamme d’indicateurs, permettant notamment d’avoir une vision du poids de la structure et des conséquences en termes de réactivité et de délai, peut être envisagée. Parmi ces indicateurs, citons par exemple : le nombre de niveaux hiérarchiques (et la répartition des effectifs dans les différents niveaux), les temps de décision (compte tenu des processus et comités existants), la base de coûts incompressibles (comment les investissements et choix passés impactent les possibilités d’investissement aujourd’hui).
• Pour changer, il faut aussi penser à réutiliser : Dans une logique d’optimisation, de l’existant comme des évolutions, trois composantes clés sont à souligner dans une approche schéma directeur : tout d’abord, l’étroite collaboration avec les utilisateurs nécessaire pour définir les besoins mais également pour pouvoir les challenger (la DSI ne doit pas oublier son rôle de conseil notamment par rapport à des choix de technologie, une cohérence globale des systèmes…). Ensuite, il s’agit de réaliser une analyse fine de l’existant et de ses capacités, en se plaçant dans une logique de réutilisation plutôt que de changement systématique. Enfin, l’évaluation du TCO (Total Cost of Ownership) permettant d’anticiper les coûts récurrents induits par les évolutions.
• Nécessité de fabiliser ses projections de consommation budgétaire pour identifier les marges de manœuvre : le sujet maîtrise et réduction des coûts est par nature déjà très orienté sur des principes de Lean Management. Néanmoins, il convient de rappeler l’importance de deux aspects de la gestion budgétaire qui concourent à une maîtrise des coûts. Le premier est l’importance de pouvoir disposer de budgets prévisibles fiables: la prévision de consommation du budget est l’élément clé permettant aux décideurs d’évaluer la marge de manœuvre dont ils disposent pour arbitrer les différents projets (il est fréquent de rejeter des projets et de ne se rendre compte qu’en fin d’année qu’il aurait été possible de les financer). Le second, qui doit être lié au premier pour permettre des réductions de coûts, est la définition des principes de réallocation budgétaire. Il apparaît nécessaire, d’autant plus en temps de difficulté budgétaire, de sortir d’un système dans lequel des économies réalisées sur un projet par une Direction sont automatiquement réengagées sur d’autres projets par la même Direction. Ces économies doivent être consolidées : soit pour les concrétiser en tant qu’économies en fin d’année, soit pour pouvoir les réallouer sur les projets prioritaires.

Une des clés de la bonne santé et de la performance d’un industriel s’avère être bien souvent sa capacité à lancer régulièrement et rapidement de bons nouveaux produits ou de bonnes nouvelles versions de produit. Mais sur quels critères ou caractéristiques l’entreprise doit-elle se baser pour qualifier un produit de bon ou de « Lean Inside » ? Ils doivent :

• être facilement fabricables : le temps entre le premier de série et la production stabilisée reste court, ils ne présentent pas d’incompatibilité avec les moyens de production existants et ils sont excellents du premier coup ;
• présenter la qualité et les fonctionnalités attendues : les lancements se font à la date prévue, sans dérapage des coûts de développement et sans perte de fonctionnalités au regard de celles désirées par le client ;
• être immédiatement fiables : l’achat des premiers modèles peut se faire sans crainte alors que dans le cas d’un industriel « non Lean », ces produits connaissent d’importants problèmes de fiabilité, de performance ou de fonctionnalité.

Les gisements de progrès qu’adresse le « Lean Engineering »

Les résultats étonnants obtenus par les entreprises qui industrialisent leurs produits selon cette approche proviennent d’actions sur :

• une conception qui prédétermine la majeure partie (75%) des coûts et de la qualité d’un produit tout au long de sa vie. Une fois un produit lancé, il ne reste que quelques leviers de progrès, essentiellement en production, pour l’améliorer ;
• un processus de développement très loin d’avoir été optimisé : beaucoup de simples bonnes pratiques, en particulier dans les entreprises occidentales, ne sont en réalité pas complètement appliquées, la faute à une relative faiblesse de l’efficacité managériale ;
• une frontière, entre la recherche et le développement non maîtrisée : de la recherche, au sens essais de solutions, se poursuit lors du développement / industrialisation avec pour conséquence de nombreux allers-retours au cours de ce process, donc des coûts en temps et en argent pénalisant pour la qualité finale du produit.

Ne lancer que des produits « Lean Inside » permet d’être sûr qu’ils ne perturbent pas la production, le réseau commercial ou les services après-vente. Alors que bien souvent des unités de production réussissent leur démarche « Lean », elles continuent de subir chaque lancement de nouveaux produits : impossibilité à fabriquer, non prise en compte de la capabilité des ressources, nomenclatures non abouties, augmentation de la variété des composants sans raison réelle…

Ainsi, en appliquant le Lean Engineering, la fiabilité d’un produit relève plus de la manière de le développer que de la façon de le produire. 

Le Lean Engineering comme reproduction du Lean Manufacturing sur les projets

La philosophie se veut la même, les outils différent. Le Lean Engineering ou Lean Product Development (LPD) n’est en fait que l’application des principes du Lean Manufacturing à la R&D, au Bureau d’Etudes et aux Méthodes. Les défis restent identiques : comment appliquer la démarche quand on ne fabrique pas de voitures ? Comment l’adapter à la culture de mon entreprise et de mon pays ? Que faut-il reproduire ou pas du système Toyota ?
Pour rassurer les industriels possédant déjà une expérience du Lean Manufacturing, le Lean Product Development requiert les mêmes basiques. En ayant déjà renforcé le poids du terrain dans son management de production et intégré l’importance de la chasse aux pertes, ces entreprises connaitront moins de difficultés à faire de même avec leurs développeurs. 

L’efficacité managériale comme incontournable

Les sociétés qui ont persévéré dans le Lean Manufacturing ne seront pas surprises de constater que l’essentiel du Lean Product Development consiste à faire évoluer le management individuel et collectif ainsi qu’à développer de nouveaux comportements.

Un des changements repose sur la mise en place de chefs de projet aux attributions très étendues, allant de la définition du besoin client, au début de la vie du produit. Ces hommes clés ne décident pas des options techniques mais consacrent leur énergie à susciter un consensus autour des choix à effectuer, et sont donc conduits à être de vrais managers. Ils incitent les développeurs à générer de vraies courbes de « trade-offs » puis à argumenter sur cette base, et ne se comportent ni en ingénieur ni en expert.

Cette transformation se heurte à de multiples barrières telles que le déficit de compétences managériales de ces populations ou l’absence d’exigence en termes de respect des délais, des spécifications et du budget d’une étape projet. 

Le recours à des techniques simples mais puissantes

Concernant l’utilisation des ressources, le Lean Product Development conduit à faire un peu l’inverse de ce qui se pratique habituellement. En effet, le Front Loading en mobilisant un maximum de ressources en début de projet, se situe presque à l’opposé de la caricature du projet mal géré et des pratiques bien souvent constatées dans certaines entreprise.

Sur le plan méthodologique, le Lean Product Development utilise des outils et techniques simples à l’image du « Visible Planning » qui vise à améliorer, de plus de 50%, l’efficience du processus de pilotage de projet par le partage visuel des informations sur les tâches et leur enchaînement au moyen de post-it. Cela constitue aussi un moyen d’introduire l’amélioration continue dans la gestion de projet et de traquer les « Mudas » (pertes ajoutées) tel que le retard pris dans le démarrage d’une tâche par manque de données d’entrée. 

Le « Knowledge » ou la gestion des connaissances au cœur de l’approche

Une des clés de la réussite des projets permettant de réduire le cycle de développement ou de ne pas se retrouver dans des impasses techniques consiste à répertorier systématiquement toutes les approches possibles et impossibles pour atteindre une spécification fonctionnelle. Il faut noter et archiver, dans une base de connaissances, ce qui fonctionne et ne fonctionne pas, pour ensuite être capable d’aller y trouver une solution à un problème ou une étude ayant antérieurement montré une non faisabilité.

Cette organisation de l’expérience acquise lors de projets précédents doit également permettre à l’entreprise de conduire en parallèle plusieurs alternatives par projet, aussi bien au niveau du design que des fonctionnalités. Cette démarche dite « d’alimentation des nouveaux projets par l’avant » (ou Feed Forward), donne aux sociétés la possibilité de retarder leur prise de décision sur une solution tout en se sécurisant sur le fait d’avoir, au terme du projet, au moins une solution opérationnelle. Même si ce thème relatif à la gestion des connaissances semble évident, il reste encore balbutiant dans de nombreuses entreprises, y compris celles dont la gestion de projet représente pourtant le cœur de leur business. 

Des résultats au-delà des attentes 

Le Lean Engineering ou Lean Product Development donne ou renforce les atouts concurrentiels des entreprises qui l’appliquent avec  :

• des produits manufacturables dont le « Ramp-up » (temps entre le premier de série et la production stabilisée en cadence et qualité) en production s’effectue en moins de deux semaines ;
• un « Time To Market » de la moitié de celui des concurrents ;
• une créativité forte mais maîtrisée basée sur une capitalisation du savoir-faire et des expériences projets précédentes.

 
par Philip Marris, Fondateur et Directeur Général de Marris Consulting

L’activité quotidienne d’une entreprise peut souvent se décrire comme un ensemble de collaborateurs qui participent à l’exécution de processus métiers. Instruments privilégiés de la création de la valeur au service des clients, la gestion des processus est donc un domaine clé, et pour lequel toute une série d’approches et de techniques ont été élaborées depuis des années.

Le BPM (Business Process management) ou gestion des processus métiers se positionne aujourd’hui comme une démarche globale qui allie analyse, exécution et supervision, dans une volonté d’intégration forte avec les systèmes d’information. L’automatisation des processus et leurs contrôles, fondée sur un ensemble d’outils et de techniques, constitue un de ces axes majeurs. Cependant, cela ne va pas sans difficultés et la connaissance des technologies ne se substitue pas à la nécessaire maîtrise des aspects métiers. Cela requiert un minimum de méthode et de structuration, afin d’en mieux contrôler la complexité.

Qu’est qu’un processus métier ?

C’est la première question à se poser, même si elle peut apparaître triviale. Trop souvent, le terme « processus » se transforme en fourre-tout, comprenant à la fois des structures de haut niveau, la description d’un enchaînement d’écrans voire un algorithme informatique.

Au cours d’un récent atelier sur le sujet, où chacun était invité à donner sa définition du terme « processus métier », le consensus a été très difficile à trouver. « Cela va sans dire, mais cela va mieux en le disant ! ». Fondamentalement, un processus métier est une transformation qui produit une valeur ajoutée tangible à partir d’une sollicitation initiale. Il est divisé en activités (ou tâches), réalisées par des acteurs (humains ou automatiques) avec l’aide de moyens adaptés,  qui contribuent chacune à l’obtention du résultat escompté. Le caractère « métier » du processus s’exprime par la nature du résultat, qui doit avoir un sens pour un client (client au sens large, interne ou externe) et mesurable.

Par exemple, dans la construction d’un bâtiment, le processus métier comprend la définition et l’organisation des tâches affectées aux différents participants. Les problèmes à résoudre portent sur la coordination, la disponibilité des ressources, l’échange et la synchronisation. A l’inverse, on va moins se préoccuper de la manière avec laquelle le maçon va s’y prendre pour construire son mur ou le charpentier pour monter la toiture. Par contre, l’ordre dans lequel ces deux tâches vont être réalisées est typiquement une question de processus.

Un processus est par nature transverse aux fonctions et entités de l’entreprise : il est constitué par les différentes étapes qui s’enchaînent de manière plus ou moins complexe à partir de la sollicitation initiale jusqu’à l’obtention du résultat final. On parle de processus « de bout en bout », porteur des indicateurs fondamentaux (KPI ou Key Performance Indicator), qui mesurent la qualité du service rendu. Cette vision à l’avantage de mettre l’accent sur le fonctionnement réel des entreprises, mais nécessite une bonne coordination entre les différentes entités impliquées. La mise en place d’une gouvernance adaptée s’appuyant sur la notion de « pilote de processus » devient un facteur clé pour la réussite des travaux.

Priorité aux processus « cœur métier »

Nous proposons de distinguer 3 niveaux de description des processus métiers : l’identification, la qualification et la modélisation proprement dite. Cette démarche se justifie par un constat suivant. Trop souvent, la précipitation à modéliser dans le détail les processus aboutit à une situation paradoxale : la prolifération de modèles difficiles à appréhender et dont la mise à jour délicate accélère leur obsolescence. Il est préférable de procéder par étapes et de disposer finalement de plans de lecture bien distincts, en fonction du type d’information recherché et du point de vue.

L’identification des processus peut prendre plusieurs formes: un simple inventaire ou une cartographie organisée. Bien entendu, on veillera à respecter les principes énoncés plus haut, de façon à conserver un haut degré d’homogénéité. Pour chaque processus un ensemble d’informations fondamentales sont regroupées dans la fiche d’identité du processus : l’évènement déclencheur, les entrées-sorties, les participants, ressources utilisée, les indicateurs clés (KPI), etc. Facilement accessible, cette fiche est le point d’entrée au processus, fournissant une vue globale et synthétique.

La qualification a pour objectif de mieux cerner les processus, et de faciliter les prises de décision. Cela part d’un constat simple : on ne peut pas mettre sur le même plan un processus totalement automatisé, exécuté 200 fois par minute, avec un autre pris en charge en majeure partie par les acteurs humains, et s’exécutant 2 fois par an. Les contraintes exercées, les compétences mobilisées, la palette de solutions, varient beaucoup d’un cas à l’autre et doivent être ajustées à chaque situation. La grille de caractéristiques va permettre de qualifier chaque processus de manière homogène à l’aide de critères directement exploitables : fréquence, complexité, durée, disfonctionnement constaté, typologie, nombre de participants etc.

La modélisation:  les modèles fondés sur une notation graphique sont incontournables pour ce type de représentation, à l’image du standard BPMN (Business Process Modeling Notation). Depuis longtemps utilisé dans beaucoup de secteurs, les modèles servent à comprendre, élaborer et communiquer. Ils constituent également un instrument majeur de conservation du patrimoine de l’entreprise. Ils requièrent des compétences particulières et un certain savoir-faire : choix du degré de détail, recueil et consolidation des informations, communication.  Suivant le but recherché, le type de modélisation sera différent : description générale, détail du processus, support pour l’automatisation. Il est recommandé de définir ces types de modèle et de toujours le préciser lors d’une communication.

Dans la pratique, le but n’est pas de fixer l’ensemble des processus de l’entreprise en une opération « big bang ». La priorité sera donnée aux processus « cœur métier », ou en fonction des opportunités de rénovation ou de modification métiers. Généralement, le nombre de processus « identifiés » est plus important que nombre de processus « qualifiés » et « modélisés », et il est conseillé de justifier clairement le passage d’un niveau à l’autre, notamment pour la modélisation, compte tenu de l’investissement nécessaire.

Pour conclure, quelle que soit la cible du point de vue technologique, il est nécessaire de soigner le volet analyse du BPM. A partir d’un cadre de structuration et des règles associées, la réussite de ce type d’opération passe également par une dose de pragmatisme et le maintient d’une vision claire sur les objectifs métiers.

Par Gilbert Raymond, Consultant Sénior  chez SOFTEAM

Dans un processus classique de conception LRU (Least Recently Used), les ingénieurs recueillent des spécifications à partir de plusieurs sources et les combinent afin d’élaborer un cahier des charges sur papier, qui aidera l’équipe de conception décentralisée à produire une conception détaillée. Cette équipe analyse une série de concepts différents par le biais de prototypes de simulation et/ou matériels, elle contrôle la conformité à ces spécifications puis elle apporte les modifications appropriées. Après avoir mis au point une conception acceptable, elle transmet celle-ci pour implémentation à une autre équipe qui exécute les tests de vérification et de validation, puis de conformité si le produit doit respecter certaines normes spécifiques. Comme les tests se déroulent à la fin d’un processus en plusieurs étapes faisant appel à des équipes différentes, les erreurs introduites en phase de conception ne sont souvent détectées que bien plus tard. Leur correction onéreuse oblige la direction à prendre des décisions budgétaires difficiles.

Détecter et corriger les problèmes dès le début du processus de conception

L’approche Model-Based Design débute par la création d’une spécification exécutable qui peut être liée aux spécifications initiales, assurant une traçabilité bidirectionnelle entre ces dernières et la conception. Cette spécification exécutable repose sur un modèle exécutable, utilisé et élaboré tout au long du processus. Elle peut également intégrer des entrées et des sorties attendues, l’environnement de l’application et une communication claire des objectifs de conception, qui vont permettre d’exécuter une analyse de faisabilité des exigences. À l’aide des liens de la spécification exécutable vers les exigences initiales, les ingénieurs peuvent vérifier que la conception respecte ces exigences tout au long du processus, et évaluer rapidement l’impact des modifications proposées.

Avec la génération de code automatique et les tests HIL (hardware-in-the-loop), les ingénieurs peuvent éliminer les erreurs introduites au cours de l’implémentation manuelle et accélérer la livraison du produit en générant le code qui servira aux tests, à la vérification et à la production finale. Par exemple, un important constructeur américain d’hélicoptères a utilisé le Model-Based Design pour développer les gouvernes d’un avion à rotors basculants, ce qui lui a permis de réduire de 40 % le temps de développement logiciel par rapport aux programmes précédents. En effet, les équipes ont pu détecter les problèmes relatifs à la conception et aux exigences et les corriger dès le début du processus de conception.

La réutilisation des modèles pour les différentes phases du processus permet également de renforcer l’efficacité des conceptions. Les ingénieurs d’un constructeur aérospatial multinational travaillant sur le programme Joint Strike Fighter (JSF) ont utilisé un ensemble commun de modèles de systèmes afin de développer trois variantes du JSF destinées à simuler les différents systèmes (avionique et propulsion, en particulier) et de générer automatiquement le code de vol final, ce qui a permis de réduire le nombre d’opérations d’ingénierie par rapport aux méthodes traditionnelles reposant sur le codage manuel.

Effectuer les opérations de test et de vérification de manière continue.

À l’aide d’un modèle, les ingénieurs peuvent tester et vérifier leur conception bien plus tôt qu’avec le développement traditionnel, pour lequel le lancement des tests nécessite une instanciation physique de la conception. Ils peuvent ensuite élaborer ce même modèle tout au long du processus de conception, ce qui leur permet d’effectuer les opérations de test et de vérification de manière continue. Avant de consacrer des ressources et des fonds à l’implémentation, à la conception ou aux tests physiques, les ingénieurs peuvent soumettre la conception à une analyse de couverture de modèle reposant sur des critères spécifiques (MC/DC, par exemple) afin de garantir la détection des erreurs dès le début du processus de conception. À ce stade, et au cas où les tests ne couvrent pas tous les aspects de la conception, l’équipe peut choisir d’effectuer des tests supplémentaires ou décider que certaines pièces de la conception ne sont pas nécessaires pour le respect des spécifications. Au cours des tests, les modèles ne sont pas limités à un environnement numérique ; ils peuvent également intervenir dans les tests portant sur les composants du système physique. Il peut s’agir par exemple des simulateurs de type « pilot-in-the-loop » développés par un important constructeur d’avions à réaction en vue de tester l’interaction en temps réel des pilotes avec les algorithmes de contrôle mis à jour, ou bien des tests HIL utilisés par un grand constructeur aéronautique afin d’étudier les problèmes intermittents de freinage sur un LRU de production.

Après avoir déterminé la pertinence de leur conception algorithmique, les ingénieurs peuvent étudier les effets de l’exécution de ce même algorithme dans un environnement embarqué. Ils peuvent ajouter au modèle des détails d’implémentation, comme le conditionnement des signaux ou l’arithmétique en virgule fixe, puis utiliser ce modèle pour créer l’implémentation de manière automatisée. Par exemple, le code C et le code HDL peuvent être générés respectivement pour une application logicielle ou une implémentation matérielle numérique. La génération automatique de l’implémentation à partir du modèle permet de supprimer les erreurs inhérentes au processus manuel. Dans la mesure où la cible de l’implémentation est spécifiée dans les étapes ultérieures du processus, il est possible de réutiliser une grande partie du travail de conception lors de la sélection d’une nouvelle cible. Par ailleurs, puisque le processus d’implémentation est automatisé, il est reproductible et ne dépend pas de la disponibilité de compétences spécifiques.

Diviser par plus de 10 les délais de mise au point et de développement global

Enfin, il est possible de réutiliser les cas de test développés au début du processus de conception pour tester l’implémentation finale. Les opérations de test et de vérification de la conception par rapport aux spécifications s’inscrivent donc sur l’ensemble du processus, et non dans ses dernières étapes. Par exemple, les ingénieurs d’une société britannique spécialisée dans la défense et l’aérospatiale et travaillant sur un système de radio réalisée par logiciel (RRL) ont pu diviser par 10 les délais de mise au point et de développement global, à l’aide de l’approche Model-Based Design. Il fallait en moyenne 645 heures à un ingénieur possédant de longues années d’expérience dans le codage VHDL pour coder une forme d’onde de SDR totalement fonctionnelle dans le cadre du flot de conception classique. Un autre ingénieur ne possédant qu’une expérience limitée a pu terminer le même projet en moins de 46 heures avec l’approche Model-Based Design. Cette amélioration considérable s’explique par le fait que le modèle, dans lequel le développeur a pu inclure tous les détails de forme d’onde des communications par satellite, était directement connecté au code résultant. Un modèle exécutable complet a permis aux ingénieurs de détecter et de supprimer les erreurs dès le début du flot de conception (et non plus au niveau des tests de comportement VHDL).

Avec l’approche Model-Based Design, les ingénieurs n’ont plus à attendre la fin du processus de conception pour effectuer les tests et contrôler que les spécifications sont respectées. En effet, ils effectuent des opérations de test et de vérification tout au long du processus, ce qui permet de réaliser des économies de temps et d’argent. Cette approche signifie que les ingénieurs peuvent effectuer les itérations de conception dans un environnement de modélisation fiable et moins coûteux, de manière à obtenir une implémentation opérationnelle dès le premier essai, avec un cycle de développement accéléré et un meilleur niveau de qualité.

Par Jon Friedman, directeur du marketing pour le secteur Aérospatial/Défense chez The MathWorks