1. Le contexte

Au cours du premier semestre 2007, le groupe mpd (Master Product Definition) du programme Phenix, démarre une activité consistant à définir une nouvelle vision de ce que doit être un plm1 du futur. Il s’agit alors plus particulièrement de définir les fonctionnalités à remplir par un plm d’entreprise capable de relever les défis d’une meilleure gestion des données techniques générées par un nombre croissant d’applications dans un système d’information en perpétuelle évolution. Ce plm d’entreprise doit maintenant être capable de supporter, en environnement virtuel, la conception d’avions de plus en plus complexes (plus de plans papiers), et d’assurer une circulation fluide des données entre les acteurs de la conception, de la fabrication, du support, et avec les partenaires externes, tout en garantissant l’accès aux données les plus à jour.

Le concept mpd englobe non seulement les capacités de pdm2 (management) mais aussi les capacités de création des données (authoring). Il devra spécifier un concept d’architecture de données capable de soutenir le plm dans son ensemble, c’est-à-dire les données techniques créées par l’ensemble des métiers et gérées en configuration sur tout le cycle de vie du produit, alors que le pdm était très centré sur la gestion des données techniques produites par le bureau d’études. En ce sens, le mpd est précurseur d’une intégration des métiers pour les fonctions de création des données métiers et de la gestion des données des différents métiers de façon cohérente par rapport au processus de modifications.

Ce groupe était constitué de dix membres représentant les divisions (BUs ou Business Units), avec des responsables pour chacune d’entre elles, Maurice Narayanin pour Eurocopter, Philippe Mussat pour Astrium, Simon Pilhar pour Military Air Systems et Claude Lancien pour Airbus. C’est en support à ce groupe que Frédéric Féru contribuera, en tant qu’architecte, à une rationalisation de la démarche qui nous rende efficaces pour les quatre métiers et prendra la responsabilité de l’évaluation technique des possibilités qui se présentaient à nous.

Afin de détailler les grands objectifs, le groupe mpd s’attèle à la rédaction de spécifications détaillées de ce futur plm d’entreprise, lesquelles décrivent les fonctionnalités de gestion des données attendues à la fois pour les domaines de l’aérospatiale et de la défense. Cela suppose d’emblée une mise en correspondance de deux logiques descriptives parfois très différentes.

Au reste, jusque-là, en fonction de ses spécificités, chaque entité du groupe eads développe son propre système d’information constitué de solutions et d’outils complètement différents. Ceci amène à dupliquer les efforts, à complexifier les communications entre systèmes, à payer des licences au prix fort et à investir dans des développements spécifiques. Ces derniers augmentent de façon significative les coûts récurrents des solutions déployées ainsi que les problèmes d’obsolescence. Avec Jean-Yves Mondon, l’équipe projet identifie un premier apport du programme Phenix, l’harmonisation des plm entre les divisions, laquelle vise la mutualisation des coûts de développements et de maintien en conditions opérationnelles. Jean-Yves nous demande alors de creuser le sujet et de travailler à la préconisation d’un outil unique (pdm) qui serait le cœur du plm répondant aux besoins de toutes les divisions du groupe. Ce nouvel outil doit supporter la gestion d’un grand nombre de données (trois millions de pièces dans un A380), pour une production en série (avions, hélicoptères, lanceurs) ou unitaire (satellite), tout en garantissant un accès sécurisé à ces données en environnement de travail collaboratif avec les partenaires.

Cet outil unique (pdm) pour l’ensemble des divisions du groupe eads représenterait une avancée majeure sur la maîtrise des coûts du système plm (volumes/prix des licences, fournisseur unique) dans un premier temps et sur la stratégie d’harmonisation et de rationalisation des interfaces/intégration dans un deuxième temps.

Ainsi, à partir des spécifications rédigées et pour concrétiser notre vision, notre but est de sélectionner un outil pdm (backbone ou colonne vertébrale du plm) capable d’implémenter les processus décrits dans les spécifications, comme la conception détaillée en environnement collaboratif qui demande des partages de données particulièrement sous contrôle puisqu’elle s’appuie sur des échanges entre entreprises différentes. Un effort particulier est mis sur l’installation de harnais électriques, d’assemblages complexes et lourds de câbles pour l’interconnexion des équipements.

Mi-2007, Jean-Yves Mondon missionne le groupe mpd et lance alors un benchmark3 mettant en concurrence les quatre principaux vendeurs de solutions existant dans le monde : Dassault Systèmes (France), ptc (États-Unis), Siemens plm Software (Allemagne) et sap (Allemagne).

Sa finalité est de choisir, de façon raisonnée, le futur fournisseur de pdm pour tout le groupe eads (120 000 employés) et pour la prochaine décennie. Il doit traduire au mieux les besoins énoncés par le groupe mpd à partir des travaux menés par le programme Phenix.

Afin de préparer le lancement du benchmark, dès mai 2007 l’ensemble des divisions s’harmonisent sur le futur concept mpd à implémenter dans le cadre du programme Phenix. Ce premier alignement entre les divisions est nécessaire afin de parler d’une même voix devant les fournisseurs potentiels.

Cette première étape permet de préparer le benchmark lors des rencontres avec les fournisseurs (période de mai 2007 à octobre 2007) mais aussi de mieux qualifier ce que nous pouvions attendre des fournisseurs (connaissance de leurs offres, leurs roadmaps, leurs modèles de partenariat). Le benchmark sera officiellement lancé en octobre 2007.

Ce benchmark ne peut cependant pas se dérouler comme il est d’usage ; avec un appel à candidature auquel répondent les fournisseurs sous la forme qui leur convient, puis l’organisation de sessions de démonstrations pour prouver leur capacité à répondre au besoin, et au final un comité décidant du candidat retenu.

En effet, il s’agit ici d’un grand groupe d’aérospatiale et de défense qui sélectionne un fournisseur de pdm parmi les plus grands fournisseurs du marché. Nous sommes observés par toute une communauté internationale sensible aux enjeux économiques (aussi bien de notre côté que de celui des fournisseurs). Les nouveaux processus plm ne sont pas totalement définis lors du benchmark et nous sommes plus à la recherche à la fois d’un backbone plm avec un pré-câblage de certains processus aéronautiques et aussi suffisamment ouvert pour soutenir nos futurs processus. Le benchmark doit aussi être un moyen pour donner du rythme et aboutir à une conclusion assez rapide pour ensuite permettre aux divisions de lancer, sans trop tarder, leurs projets de transformation.

Effectivement, certaines divisions, comme Eurocopter, avaient déjà lancé, en 2006, une initiative d’amélioration de ses outils de gestion de configuration. En 2007, Eurocopter était aussi sur le point de lancer des consultations de choix d’outils. S’ajoutent à tout cela des enjeux politiques liés au fait qu’un groupe européen d’aérospatiale, mais surtout de défense, mette en concurrence des fournisseurs européens et américains.

Les résultats du benchmark doivent être basés sur des critères de choix indiscutables. Éviter toute contestation ou suspicion de favoritisme demande alors la mise en place d’un processus de sélection transparent et impartial. Nous nous fixons donc l’objectif d’évaluer les fournisseurs sur les mêmes bases et avec les mêmes règles, sans possibilité de contestation ultérieure.

Le succès du benchmark repose alors sur les critères suivants :

– intégration des initiatives de divisions ;

– méthodologies de benchmark n’amenant aucune contestation possible des divisions et/ou des fournisseurs ;

– méthodologies de benchmark capables de maîtriser certains fournisseurs qui comptaient plus sur les aspects politiques ;

– visibilité des résultats dans le groupe eads ;

– capacité à embarquer les experts des divisions.

Toute l’équipe mpd a bien compris l’ensemble des enjeux liés à ce benchmark et nous devons être exemplaires pour le succès du programme Phenix. L’échec du benchmark signifierait la mort du programme Phenix et ne plus disposer du support du groupe eads pour faire avancer les projets de transformation en plm dans les divisions.

À partir de juin 2007, le travail de l’équipe mpd est très vite organisé afin de préparer ce benchmark. Grâce au support des Achats stratégiques du groupe, nous mettons en place le processus suivant :

– rfi (Request For Information) envoyé dès l’été 2007 ;

– rfq (Request For Quotation) envoyé dès l’été 2007 afin de faire déjà une première analyse du marché ;

– rfp (Request For Proposal) pour le pilote mpd qui est le lancement officiel du benchmark mpd. Le rfp est envoyé en octobre 2007 ;

– Application du pilote mpd dans le contexte du programme Tigre chez Eurocopter.

Les discussions avec Jean-Yves Mondon démarrent en février 2008. Le pilote mpd pour le programme Tigre se terminera en octobre 2008.

2. Organisation, mise en place et déroulement du Benchmark

Le groupe mpd définit alors le benchmark et le décompose en quatre phases distinctes, l’achèvement de l’une conditionnant le début de la suivante.

2. 1. La préparation

La première phase est consacrée à la préparation. C’est un très gros travail d’identification et de mise en forme des besoins qui s’étend d’octobre à fin décembre 2007. De façon à les impliquer au plus tôt, Jean-Yves Mondon envoie dès le début une lettre officielle d’invitation aux quatre plus grands fournisseurs de solutions pdm leur expliquant notre objectif. Il leur demande de se prononcer sur leur intérêt à participer à ce benchmark. Trois d’entre eux répondent positivement : Dassault Systèmes, ptc et Siemens plm. sap décline officiellement, estimant que son offre plm n’est pas assez mature et complète pour répondre à nos exigences. Cette décision de sap a extrêmement surpris l’équipe mpd et le programme Phenix. Lors des réunions préparatoires, sap semblait très motivé et voulait développer son activité plm.

C’est aussi lors de cette phase que le groupe mpd termine la rédaction des spécifications détaillées du futur pdm d’eads ainsi que la description des scénarios à jouer lors des tests des outils (en phase 2). Dès la fin novembre 2007, les fournisseurs prennent connaissance de ces documents afin qu’ils puissent se préparer et définir leur plan d’action pour jouer les tests dès janvier 2008.

Le programme des tests est divisé en quatre niveaux d’évaluation à effectuer entre janvier et avril 2008. Comme décrit dans les spécifications publiées en novembre 2007, chaque niveau de test va crescendo dans la difficulté et suit le processus suivant :

– préparation par chaque fournisseur ;

– présentations par chaque fournisseur (à huis-clos) devant des experts venus de tout le groupe eads ;

– Bilan individuel des résultats obtenus par chaque fournisseur sans communication détaillée des notes obtenues.

Dès octobre 2007, nous identifions le besoin d’accueillir tous les acteurs du benchmark technique sur un même site pour en faire un lieu de rencontre et de travail. C’est pourquoi nous décidons de chercher et d’aménager un plateau capable de contenir les quatre fournisseurs dans quatre salles isolées, dont une grande pour les briefings et trois plus petites pour les réunions. Nous décidons aussi que le plateau doit comporter une infrastructure informatique indépendante (hors réseau eads) avec du matériel et des capacités de stockage de données.

Les fournisseurs doivent pouvoir disposer d’un espace à eux pour y installer leurs outils informatiques et y présenter leurs résultats. De plus, dans un souci d’équité, ils ont exactement le même matériel informatique sur lequel préparer, élaborer et jouer les tests. Ce sont également les mêmes jeux de données de test (modèles géométriques, etc.) qui sont communiqués à chacun. Ces jeux de données sont fournis par les divisions et représentent des exemples industriels permettant de tester différents aspects des solutions (fonctionnels, techniques, chargement des données et performances).

De plus, afin de garantir la confidentialité nécessaire, le niveau de sécurité du plateau doit être important tout en permettant l’accueil de personnes venant du monde entier.

La localisation du plateau chez cimpa à Toulouse4 est proposée, validée et mise en œuvre. Les fournisseurs seront libres de venir sur le plateau avec les moyens humains qui leur sembleront nécessaires à condition de travailler dans les locaux et avec le matériel mis à disposition.

Des experts nommés par les divisions du groupe viendront évaluer les résultats des tests et rempliront les fiches d’évaluation (1 fiche par test). Après la fin du quatrième niveau de test, deux jours supplémentaires permettront de rejouer les tests qui auront échoué pour ainsi améliorer la notation finale.

C’est à ce moment-là que Jean-Yves Mondon demande à :

– F. Féru (alors en poste au Centre de Recherches du Groupe eads) de prendre la responsabilité du benchmark technique. Ses compétences et ses aptitudes de coordinateur ainsi que ses connaissances techniques des pdm du marché et des outils implémentés dans les divisions ont guidé le choix de Jean-Yves. Ce travail de coordination doit être assuré par un responsable du groupe eads sans pour autant que celui-ci soit membre d’une des divisions afin d’éviter tous conflits avec les autres divisions.

– M. Schrepfer de coordonner la préparation de la synthèse du benchmark pour la présentation au Comité de sélection.

– M. Narayanin, qui a rédigé le cahier des charges du benchmark et défini la méthodologie, de coordonner, avec F. Féru, l’analyse des résultats des tests.

– P. Mussat, qui a coordonné la rédaction les spécifications du mpd, de vérifier la cohérence des tests par rapport au modèle mpd.

Un tel dispositif permet ainsi d’éviter que les fournisseurs aient un seul point d’ancrage pour ce benchmark.

Courant novembre 2007, Frédéric Féru supervise le démarrage de deux chantiers avec pour objectif d’être prêt à la mi-décembre :

– établissement des plans, lancement et suivi des travaux pour les locaux ;

– définition et mise en place de l’infrastructure informatique (elisa) comprenant les réseaux, les bases de données, les ordinateurs, etc.

Une organisation est aussi définie et mise en place pour gérer le benchmark technique. Elle est en charge d’offrir les meilleures conditions pour que les tests se déroulent au mieux, de gérer les communications entre les fournisseurs, l’administrateur informatique, la sécurité, etc., et d’assurer la descente et la remontée d’informations de et vers Jean-Yves Mondon et le groupe mpd.

2. 2. Le déroulé des tests et la notation

Le benchmark technique proprement dit est la deuxième phase. Allant de janvier à avril 2008, elle consiste à dérouler le programme de tests prédéfinis préparé par le groupe mpd et pour lequel chaque fournisseur doit démontrer les capacités de son outil à répondre au besoin au travers de tests prédéfinis.

Comme prévu, tout est prêt à la mi-décembre 2007 et le 7 janvier 2008, nous accueillons les premières personnes sur le plateau à Toulouse. Il s’agit des responsables et acteurs de l’avant-vente de ptc qui viennent prendre possession des lieux et se préparer à démarrer les tests dans les meilleures conditions. Siemens se présente un peu plus tard suivi de Dassault Systèmes.

Chaque fournisseur a à sa disposition sa propre salle ainsi que tout le matériel informatique nécessaire. Dès l’arrivée d’une nouvelle personne (arrivée annoncée à l’avance par les fournisseurs), celle-ci doit tout d’abord se plier aux formalités de sécurité afin de se voir attribuer un badge lui donnant les droits d’accès aux locaux. S’agissant de personnes venant du monde entier, cette formalité peut prendre plus ou moins de temps en fonction de la nationalité, mais surtout si nous n’avons pas été avertis auparavant.

Les fournisseurs ont jusqu’au 21 janvier 2008 pour installer leurs outils et se préparer à jouer les tests attendus. Le 17 janvier 2008, j’organise une réunion de lancement officiel avec tous les acteurs présents (25 personnes) : les membres du groupe mpd et les représentants des fournisseurs. Lors de cette réunion, Frédéric Féru rappelle les règles de déroulement du benchmark technique ainsi que les critères d’évaluation. Il décrit aussi l’organisation mise en place et les contraintes logistiques (horaires d’accès, déjeuner, etc.).

Le benchmark technique se déroule du 8 janvier 2008 au 15 avril 2008 dans les locaux du cimpa à Toulouse. Les trois fournisseurs ayant accepté de participer y ont été évalués sur leur capacité à mettre en œuvre les scénarios de tests élaborés par le groupe mpd (avec des données réelles que nous leur fournissons) et à répondre aux questions des experts présents.

Les tests sont divisés en quatre niveaux d’évaluation, chaque niveau poussant un peu plus loin les difficultés à surmonter. Les premières phases consistent à vérifier la bonne adéquation des fonctionnalités de base des outils avec nos besoins (gestion des accès utilisateurs, administration des bases de données, etc.), puis à vérifier les capacités à gérer la conception, à supporter le travail collaboratif en interne puis avec des partenaires, et enfin à s’intégrer dans les systèmes d’informations existants.

Un nombre prédéfini de tests doit ainsi être joué par chaque fournisseur. À chaque test correspond une grille d’évaluation à remplir par le groupe d’experts présent. En effet, lors de chaque session, des experts venant de toutes les divisions du groupe sont invités à venir évaluer les résultats présentés.

Tout au long de cette période, ce ne sont pas moins de 90 experts qui se succèdent pour évaluer 284 tests pour chaque fournisseur. Ils rédigent ainsi 852 (284  3) grilles d’évaluation hiérarchisées en quatre niveaux. Nous avons aussi la chance de recevoir Guillaume Faury (Directeur technique d’Eurocopter).

Un premier niveau de tests se déroule entre le 21 janvier et le 1^er février. Il est constitué de 100 tests concernant les fonctions techniques de base comme la sécurité ou l’organisation du progiciel. Ainsi, sont analysés comment les utilisateurs sont identifiés, ce à quoi ils ont accès, en d’autres termes les mécanismes de configuration et d’attribution des droits à utiliser tel ou tel type de données, comment ces droits sont compatibles entre les différents logiciels proposés dans la solution. Le progiciel est observé du point de vue de son architecture (sa composition globale et les relations entre ses composants), de ses performances comme les temps de réponse à l’envoi de requêtes. On s’intéresse aussi à l’ergonomie à travers le nombre de clics nécessaires pour atteindre une information et à la fiabilité des moyens d’archivage long terme qui sont indispensables dans tous les métiers de l’aérospatiale.

Un deuxième niveau, entre le 4 et le 8 février comporte 36 tests sur les fonctions plm de base, à savoir la qualité des données, en l’occurrence les innombrables documents, modèles 3D, schémas, etc. qu’il faut organiser en bibliothèques et pouvoir retrouver simplement. Il y a aussi la mise en œuvre de processus comme le suivi et la validation des changements : l’évolution des données est un point très important d’une façon générale puisque la conception d’un produit complexe se fait pas à pas avec des améliorations progressives et il est indispensable d’assurer la traçabilité des modifications qui sont apportées. Elle est plus importante encore dans un environnement multi-entreprises dans lequel des rsp (Risk Sharing Partners) partagent la conception du produit. La qualité des données est ici l’assurance que les remontées des nouvelles versions de tel composant n’entrent pas en contradiction avec la nouvelle version d’un autre, par exemple que les interfaces restent compatibles.

Un troisième niveau de 64 tests, entre le 18 février et le 7 mars, creuse les fonctions avancées du plm. On est ici dans l’intégration des données liées aux modèles cao et gérées en configuration qui se traduit par des arborescences qui décrivent les sous-ensembles d’un sous-ensemble donné. La capacité à insérer une arborescence (pouvant correspondre aux composants fournis par un fournisseur) est évaluée sous plusieurs points de vue. L’envoi des données vers l’extérieur doit être à un niveau de normalisation qui assure qu’elles soient lisibles dans un système différent. La conformité aux standards doit donc être testée. En réception, il faut s’assurer que les branches prennent correctement place dans l’arborescence générale représentant le produit (avion, satellite, hélicoptère). Dans cette adéquation se place la relation avec la maquette numérique (dmu pour Digital Mock-up) qui s’appuie sur toutes ces données pour représenter virtuellement le produit. Signalons rapidement que la dmu, en affichant la géométrie de l’avion, en permettant de zoomer, de se déplacer, est un puissant outil de décision sur les problèmes éventuels de clash ou d’allocation d’espace à l’intérieur du produit. Enfin sont testés les échanges avec les systèmes de planification des ressources des usines ; cette interface est un élément très important de la relation entre conception et fabrication, entre bureau d’études et ateliers.

Enfin, le quatrième niveau, de 83 tests, se déroule entre le 17 février et le 4 mars. Ce sont alors des processus de conception transverse qui sont étudiés à travers des scénarios produits par des équipes d’Airbus, d’Eurocopter, de Defense & Space et d’Astrium.

Pour en donner un aperçu, citons Design in Context, qui modélise l’ensemble des actions nécessaires à l’accueil d’un concepteur dans un groupe de travail. Il faut en effet identifier la personne, en déduire son rôle et la zone concernée. Le contexte dans lequel il ou elle travaille se traduit par un ensemble de pièces voisines, la mise à disposition des données les concernant, l’historique de la pièce elle-même qui est à concevoir, éventuellement la capacité à la créer. Il y a ensuite toutes les tâches d’insertion du travail dans un ensemble plus grand, d’identification univoque, de soumission pour validation, de conservation, de capacité à le retrouver, etc.

On peut également citer le processus de gestion des Ground Support Equipment qui, au contraire du précédent, ne traite pas des informations du produit final, mais des équipements et outils nécessaires quand celui-ci est au sol. Un avion ou un hélicoptère fait l’objet de nombreuses opérations de maintenance ou d’avitaillement qui nécessitent des équipements particuliers qu’il faut concevoir, planifier et mettre en œuvre. Rationaliser ce processus est un moyen de maîtriser les coûts opérationnels, ce qui constitue pour l’aéronautique un argument de vente fort.

À la fin de chaque niveau, et pour chaque fournisseur, Frédéric Féru organise un retour formel sur les résultats obtenus, sans pour autant communiquer le détail de la notation. Le rapport détaillé est en effet réservé à la direction du programme, de façon à ce que les informations concernant un éditeur ne soient pas connues de ses concurrents.

Les 14 et 15 avril, chaque fournisseur a la possibilité de rejouer les tests (40 maximum) qui ne se sont pas bien déroulés pour lui permettre d’améliorer sa note finale.

Une fois le niveau 4 terminé et, comme après chaque niveau, Frédéric Féru communique à chaque fournisseur les résultats globaux qui sont les scores obtenus dans les quatre phases de tests. Puis il prononce la fin du benchmark technique.

2. 3. La consolidation

Une troisième phase, de consolidation, s’étend d’avril à mai 2008. Frédéric Féru a alors remis les résultats du benchmark au groupe mpd qui les exploite, les analyse et les utilise pour des négociations commerciales avec chaque fournisseur.

Lors de cette troisième phase sont donc évaluées les propositions de chaque fournisseur dans leur globalité (et donc non plus seulement sous l’aspect technique) et selon les critères suivants :

– stratégie et partenariat ;

– offre commerciale et contractuelle ;

– services et supports ;

– coût de possession.

En fonction de toutes les informations collectées, les résultats complets sont rédigés et des recommandations sont énoncées pour préparer le choix final.

2. 4. La décision

Enfin, la dernière phase (en juin 2008) rassemble un comité de sélection pour prononcer la décision finale. Celle-ci s’appuie sur trois axes : la disponibilité que l’éditeur déploie autour du produit, ses usages et ses capacités techniques, les couts de possession et la proximité aux besoins d’eads.

Le groupe mpd rédige alors un rapport final qui est validé par Jean-Yves Mondon le 2 juin 2008. Ce rapport met en avant la qualité technique des offres de Siemens et de ptc dont les notes sont équivalentes (avec une légère avance pour le premier) et au-dessus du niveau attendu. Le résultat des négociations commerciales et de supports y est aussi exposé et c’est ptc qui en ressort avec un net avantage.

Le 17 juin 2008, Jean-Yves Mondon réunit un comité de sélection composé des directeurs techniques et informatiques des différentes divisions (Airbus, Astrium, Eurocopter, Military Air Systems, Military Aircrafts) et présidé par le directeur technique du groupe. Au fil de la discussion, aucune divergence n’apparaît et un consensus est établi.

Le comité suit donc les recommandations et décide de signer un contrat avec la société ptc.

Depuis ce jour, Windchill (le pdm de la société ptc) est déployé dans toutes les divisions du groupe.

3. Conclusion

La méthode de sélection de la solution pdm, dans sa partie technique, présente des avantages qui ont été bien identifiés. Le benchmark produit un double effort : les éditeurs sont fortement motivés, ils présentent leurs meilleurs ingénieurs et sont d’une réactivité inhabituelle (avant-vente oblige) et l’équipe mpd est obligée de formaliser de façon importante les besoins, ce qui réclame la mobilisation de nombreuses compétences qui est assez fédératrice. Les écarts entre les performances des différents fournisseurs doivent être rapidement analysés et compris.

Il y a en parallèle un avantage réciproque : les éditeurs creusent profondément les possibilités de leur produit, bien au-delà de ce qu’ils font d’ordinaire et leurs ingénieurs acquièrent pendant les tests des connaissances supplémentaires sur les métiers de l’aérospatiale. Cela a un impact positif sur leur vision et leur compréhension de nos exigences.

De notre point de vue, les discussions très poussées entre Phenix et les fournisseurs, la nécessité de faire comprendre les spécifications, les incessants allers-retours et les explications à apporter obligent à clarifier ses idées, à mûrir un domaine dont les détails sont innombrables. Par exemple, si les phases de 1 à 3 sont restées assez formatées, les scénarios de la phase 4 ont été ajustés.

Mais l’exercice comporte des limites naturelles. Tout le contenu du benchmark est communiqué avant que celui-ci ne commence, ce qui oblige à un travail initial très lourd qu’il n’est pas possible de reproduire souvent. Les impératifs de confidentialité obligent à protéger les informations provenant des concurrents, mais la transparence du processus de décision oblige à en dire assez. Dans le même esprit, eads doit livrer des scénarios pertinents et réalistes tout en se gardant de révéler des données sensibles. En 2008 ont été fournies des données très en prise avec l’utilisation du moment et ce fut un gros travail de les expurger.

Ainsi, un benchmark se déplace sur une ligne de crête entre deux versants : la confiance (même si encadrée par un nda – Non Disclosure Agreement) et l’équité qui oblige à cloisonner les échanges.

Il faut croire que celui-ci a su garder l’équilibre : pas un des fournisseurs et/ou division n’a contesté les résultats ou la méthodologie employée.