PBS : un levier majeur de l`Ingénierie Système

“PBS : un levier majeur
de l’Ingénierie Système”
Une réflexion thématique proposée par Thales Systèmes Aéroportés
Edmond TONNELLIER
+33 (0) 1 34 81 99 54
[email protected]
2 Avenue Gay Lussac, 78851 Elancourt Cedex, France
..
Olivier TERRIEN
+33 (0) 1 34 81 75 21
[email protected]
2 Avenue Gay Lussac, 78851 Elancourt Cedex, France
Résumé :
En 2012, Thales Systèmes Aéroportés a mené une réflexion sur le Product Breakdown Structure
(PBS) et le rôle central de cet outil dans l'Ingénierie des Systèmes. En effet, tout au long du cycle de
vie d’une Solution coexistent une multitude de décompositions arborescentes et leurs similitudes apparentes suggèrent, d'une façon simpliste et réductrice, que ces représentations ne sont qu’une redondance inutile due à des métiers complémentaires qui désignent une même réalité de manières différentes.
Au travers d’une étude plus précise des normes internationales et grâce à un examen plus attentif des
étapes d’utilisation de ces diverses arborescences, ce papier montre à quel point leurs finalités sont différentes et comment elles mettent en évidence des caractéristiques spécifiques du système à concevoir,
à produire, à maintenir, etc. Ceci dit, une confusion entre tous ces outils existe et c’est pourquoi ce document aborde une question de principe : « Est-ce que cette confusion provient de normes imprécises
et peu explicites sur le sujet, d'interprétations erronées de celles-ci par les architectes de futurs systèmes ou bien d'approximations et d’à-peu-près dans l’usage de ces outils qui structurent et dimensionnent les projets en R&D ? ». Une réflexion thématique pour éclairer un levier majeur pour l’Ingénierie
des Systèmes.
Figure 1. Logo du Symposium INCOSE
(INternational Council on Systems Engineering)
TSA1049722-02
Copyright © THALES 2012 - E.Tonnellier & O.Terrien
1
Sommaire :
1. Contexte
3
2. Problématique posée par les arborescences
2.1 Question de principe
2.2 Enquêtes & Benchmarks
2.3 Diagnostic
2.4 Structure du document
2.5 Approche Lean Engineering
4
4
5
5
6
6
3. PBS & Offres
3.1 Processus d’Offre
3.2 Définition du PBS
3.3 Niveaux de visibilité & critères d’arrêt
3.4 Illustration d’un PBS en phase Offre
3.5 Exemple d'atelier Lean Engineering en phase Offre
8
8
8
9
9
10
4. PBS & Projets
4.1 Processus de développement
4.2 Arborescence de développement
4.3 Articles de configuration & critères de choix
4.4 Illustration d’une arborescence de développement
4.5 Stratégies d’IVVQ
4.6 Exemple d'atelier Lean Engineering en phase Projet
12
12
12
13
13
13
14
5. PBS & Productions
5.1 Processus de production
5.2 Arborescence de définition
5.3 Arborescence logistique / critères d’échange
5.4 Illustration d’une arborescence de définition
5.5 Exemple d’un atelier Lean en Support Client
15
15
15
15
16
16
6. Conclusion
17
7. Bibliographie
17
8. Remerciements
17
9. Auteurs
18
TSA1049722-02
Copyright © THALES 2012 - E.Tonnellier & O.Terrien
2
1. Contexte
Thales Systèmes Aéroportés est une société du Groupe Thales, rattachée
à la Division Systèmes de Mission de Défense (DMS).
Figure 2: Chiffres clés du Groupe Thales
Thales Systèmes Aéroportés est actuellement le leader européen et le troisième acteur mondial sur
le marché des équipements et des systèmes de mission de défense aéroportés et navals. La société
conçoit, développe et produit des solutions à la pointe de l’innovation technologique pour des plateformes aussi variées que des avions de combat, des drones, des avions de surveillance ou encore des
navires et des sous-marins.
Environ 20% de son chiffre d’affaires est consacré aux activités R&D dont une large proportion
pour l’Ingénierie des Systèmes. Implantée dans plusieurs pays européens, elle emploie nombre
d’experts hautement qualifiés pour imaginer les solutions au plus près des besoins de plus en plus
complexes de ses clients. Bénéficiant de positions traditionnelles de premier plan dans les systèmes de
renseignement électronique et de surveillance, d’un savoir-faire reconnu dans les radars pour avions de
combat ou en guerre électronique, Thales Systèmes Aéroportés implique ses clients dès la phase de définition des solutions jusqu’à la validation opérationnelle des produits. Cela nécessite des projections à
long terme pour faire face aux longs cycles de développement, production et opération.
La complexité des systèmes développés au sein du groupe Thales provient du nombre de matériels
intégrés, de la multitude des technologies utilisées ou encore du volume des logiciels embarqués. La
combinaison désormais systématique de contraintes techniques et non techniques lors des nouveaux
contrats oblige les équipes à synchroniser de plus en plus finement des compétences issues de disciplines complémentaires dont les acteurs sont souvent répartis dans plusieurs pays. De plus, la concurrence internationale et l’effet de la conversion euro/dollar entraînent d’importantes contraintes budgétaires (en coûts récurrents et non récurrents) imposant réutilisations et/ou mutualisations. Enfin, le
rythme accéléré des développements impose des définitions approfondies mais aussi une forte réactivité aux aléas ou aux défauts rencontrés, conséquences inévitables de l’évolution rapide des besoins et
des marchés. C'est pourquoi la structure des produits et l’organisation des activités sont des facteurs
clés du succès de projets en R&D.
En 2012, Thales Systèmes Aéroportés a lancé une étude sur le PBS (Product Breakdown Structure)
comme levier central pour l’Ingénierie des Systèmes, et cela tout au long du cycle de vie d'une Solution. Grâce à plusieurs offres et projets en développement, les auteurs de ce document ont observé des
pratiques vertueuses en matière d'utilisation d’arborescences existantes. Ce document peut être considéré comme un témoignage industriel et concret de la contribution positive du PBS dans l’Ingénierie
des Systèmes pour des solutions à longs cycles de vie et à des niveaux élevés de risques.
TSA1049722-02
Copyright © THALES 2012 - E.Tonnellier & O.Terrien
3
2. Problématique posée par les arborescences
Fondamentales pour gérer la configuration d’une Solution, les arborescences sont des représentations structurées où se retrouvent les divers constituants de cette solution (une décomposition ou
« breakdown » en anglais, une forme en arbre avec ses ramifications ou « tree frame » en anglais).
Tout au long de la vie d’une Solution, il en existe une multitude pour supporter les divers processus
techniques nécessaires pour concevoir, développer, produire… cette solution. Les similitudes flagrantes entre ces diverses représentations laissent à penser de manière simpliste et réductrice qu’il ne s’agit
que de redondances inutiles dues à des métiers complémentaires qui désignent de manière différente
une même réalité. Toutefois, une relecture plus précise des normes internationales et un examen plus
attentif du positionnement de ces arborescences montrent combien leurs finalités sont différentes et
comment elles mettent en évidence des caractéristiques particulières du système à concevoir.
2.1 Question de principe
Une question de principe posée par un participant à la préparation d’un nouveau développement a
déclenché cette réflexion sur l’usage du Product Breakdown Structure (PBS). Lors de cet atelier collaboratif destiné à l’ajustement des activités à mener pour une future solution, nous nous sommes interrogés sur la compréhension, l’utilisation et la maîtrise du PBS tout au long des projets en R&D. La
question initiale comportait en elle-même les indices d’une confusion possible entre ces multiples arborescences techniques dans l’Ingénierie des Systèmes ?
System
System of
Interest
SubSystem
Enabling
System
SubSystem
Development
System
Training
System
Production
System
‘System of Interest’ Breakdown
Disposal
System
Support
System
‘Through Life Cycle Enabling Systems’ Breakdown
Figure 3: Décomposition typique d’un système / d’une solution
Au départ de notre réflexion, cette question : « Est-ce que la confusion ressentie provient de normes
peu précises et/ou peu explicites sur le sujet, de l’interprétation incorrecte ou erronée de ces arborescences par les concepteurs d’un nouveau système ou d’une pratique de l’à-peu-près dans l’usage
d’outils qui structurent et dimensionnent les projets en R&D ? ».
Notre réflexion s’articule donc autour de ces trois thèmes :
La définition incomplète et/ou imprécise des arborescences techniques dans les processus de
conception et de développement ;
Leur appropriation et leur utilisation réelle à chaque phase du cycle de développement d’un
produit/d’une solution ;
Le comportement des concepteurs entre ‘trop’ et ‘trop peu’ lors de développements de systèmes
complexes et le niveau de visibilité associé.
TSA1049722-02
Copyright © THALES 2012 - E.Tonnellier & O.Terrien
4
2.2 Enquêtes & Benchmarks
Pour dépasser la théorie des textes et pour observer l’application des arborescences sur le terrain,
nous avons mené de nombreuses interviews auprès de différents contributeurs au développement d’un
produit/d’une solution. Plusieurs benchmarks auprès de sociétés qui mettent en œuvre des processus
de conception longs et risqués ont confirmé le risque potentiel d’un usage incomplet, incorrect ou imprécis des arborescences techniques citées spontanément lors des rencontres que nous avons faites.
Un des constats immédiats de ces interviews résulte de l’inévitable incertitude liée au futur. Face à
l’inconnu, deux comportements diamétralement opposés : d’un côté, la volonté d’anticiper toute situation possible par une description dans les moindres détails d’une solution dès les premiers coups de
crayon et d’un autre côté, le choix de ne traiter que les problèmes apparus pour ne pas multiplier les
efforts d’élimination de situations bloquantes mais dont l’apparition reste incertaine. Dans le premier
cas, une description dans les moindres détails peut engendrer une complexité humainement impossible
à gérer et donc inacceptable. Dans le second cas, une réaction aux seuls problèmes survenus peut provoquer un engorgement de dangers impossibles à surmonter et donc inacceptable.
Ce constat montre combien les choix faits par l’Ingénierie des Systèmes sont au cœur de cette problématique des arborescences : « Quel niveau de visibilité et quelle profondeur d’analyse sont requis
pour maîtriser la complexité d’un nouveau développement ? ».
2.3 Diagnostic
Plutôt que de raisonner dans l’absolu des théories ou de jouer sur les subtilités techniques des outils,
cherchons à illustrer de manière caricaturale la confusion possible entre plusieurs représentations à notre disposition.
Le ‘quoi’, le ‘comment’ et le ‘qui’ :
Imaginons une équipe technique qui ne s’attacherait pas à la livraison de produits mais qui ne se
concentrerait que sur sa charge de travail. Pourquoi utiliser un PBS (Product Breakdown Structure)
alors qu’une autre représentation, le WBS (Work Breakdown Structure), contient directement les activités à mener ?
Le raccourci est tentant, d’autant que le travail à réaliser se base alors sur les standards ou les processus d’un métier. L’envie de court-circuiter le PBS pour établir directement un WBS révèle pourtant
une confusion possible entre le ‘quoi faire’ et le ‘comment faire’. En supprimant les choix itératifs et
les interactions avec le PBS, ce WBS devient plus rapide car il limite les efforts pour son élaboration.
Mais en oubliant le ‘qui commence quoi’, ce WBS comporte des incertitudes et des ambigüités sur la
réalisation à terminaison. A la facilité apparente du début, la multiplication des difficultés en fin du
projet. Cette confusion des finalités entre PBS et WBS s’accentue encore lorsque l’OBS (Organisational Breakdown Structure) se superpose aux activités à affecter aux divers protagonistes du projet.
‘Le développement d’une solution’ et ‘la solution développée’ :
Prenons maintenant une équipe uniquement composée de concepteurs et d’architectes, et qui prépare son prochain développement. Pourquoi utiliser un PBS (Product Breakdown Structure) alors qu’une
autre représentation, l’arborescence de développement (Development Breakdown en anglais), contient
directement les caractéristiques fonctionnelles du système à concevoir ?
Certes, ce raccourci est tentant car cette arborescence de développement supporte toutes les spécifications de la nouvelle solution. Mais que deviennent tous les systèmes facilitateurs pour tester, pour
produire, pour former, pour maintenir, etc (‘Enabling Systems’ en anglais) ? L’envie de ne se focaliser
que sur le produit principal (‘SOI, System Of Interest’ en anglais) témoigne d’une confusion entre le
but à atteindre et le parcours pour y arriver. En oubliant les éventuelles maquettes préliminaires ou les
moyens de validation spécifiques (simulateurs, bancs de test, etc), l’acceptation du produit par le client
ainsi que les livraisons des exemplaires suivants seront d’autant plus difficiles.
TSA1049722-02
Copyright © THALES 2012 - E.Tonnellier & O.Terrien
5
Développement (NRC) et Production (RC) :
Considérons désormais une équipe concevant un nouveau système qui sera reproduit en plusieurs
dizaines voire centaines d’exemplaires. Pourquoi utiliser un PBS (Product Breakdown Structure) alors
qu’une autre représentation, l’arborescence de définition (Design Breakdown en anglais), identifie
tous les constituants matériels et logiciels à réutiliser, à acquérir et à assembler ?
Le raccourci est tentant surtout si le nouveau système ré exploite de nombreux éléments déjà développés. Certes, cette arborescence de définition fournit dans ce cas un ordre de grandeur satisfaisant du
coût global de la future solution mais elle néglige les hypothèses de réutilisation, les marges de reproductibilité ou encore les disponibilités des moyens pour valider, faire et maintenir. L’envie de déterminer rapidement l’essentiel des dépenses en se focalisant sur les coûts récurrents (‘RC, Recurring
Costs’ en anglais) révèle une confusion sur les dépenses et sur l’engagement des dépenses, une incompréhension entre celui qui paie et celui qui décide de ce qui sera à payer durant le projet. Si les coûts
de développement et de validation (‘NRC, Non Recurring Costs’ en anglais) s’avèrent minoritaires
dans les dépenses totales d’un système, ils correspondent à l’engagement du reste des coûts pour le
cycle de vie complet de ce système : y compris sa production, son maintien en opération jusqu’à son
retrait de service. En oubliant l’effort initial à fournir pour structurer sa solution, l’équipe démarre son
projet avec une fragilité de ses hypothèses, fragilité d’autant plus dangereuse au fur et à mesure de
l’avancée dans le cycle de vie de la solution.
Le re-use, les lignes de produits, la sous-traitance et l’interchangeabilité :
Imaginons enfin une équipe commerciale qui élabore une offre concernant un nouveau système
dont les constituants majeurs sont déjà en production. Pourquoi utiliser un PBS (Product Breakdown
Structure) alors que la concaténation de sous-parties de précédentes arborescences de définition répond à peu près à la sollicitation ?
Le raccourci est tentant car, si tout se passe bien, le nouveau système sera similaire aux précédents.
Cependant, l’envie de figer rapidement une définition néglige les conditions d’utilisation des constituants, leurs limites (in)connues d’utilisation ou encore les hypothèses de réutilisation. En général, la
combinaison de risques unitaires génère un risque global beaucoup plus important que la simple sommation des points durs pris séparément. Estimer une nouvelle solution pour une offre se base en effet
sur la somme de modèles de coûts élémentaires mais aussi sur une combinaison des risques et sur les
dérives potentielles de chacun des constituants du système complet. La confusion entre ces deux structures provient de l’oubli de la part invisible et négative des interactions et des choix effectués.
2.4 Structure du document
Pour des solutions aux cycles de vie longs et aux niveaux élevés de risques, chaque phase d’un développement identifie ses propres coûts et ses points durs. Toutefois, chaque phase ne peut rapidement
estimer les risques et les dérives qu’elle génère pour le reste du cycle de vie de la solution en conception. Il s’agit pourtant là d’un levier essentiel pour la maîtrise du coût global d’un projet. Un optimum
local peut s’avérer dangereux pour le projet dans sa globalité. Si l’acquéreur d’un nouveau système
appréhende rapidement les coûts d’acquisition et de développement, il doit aussi considérer les coûts
globaux de son système, y compris les surcoûts probables et les risques possibles pour chacun des aspects du cycle de vie complet : exploitation, réparation, formation… jusqu'au retrait de service. Ce document illustre ces phases avec les contributions possibles du PBS pour chacune d’entre elles.
2.5 Approche Lean Engineering
En 2007, Thales Systèmes Aéroportés a lancé une initiative Lean Engineering. Une approche Lean
n'est pas une miraculeuse boîte à outils mais une méthodologie pragmatique visant à aider projets,
équipes ou personnes (et donc les activités au travers du WBS) en ayant sans cesse l'obsession des besoins du client (et donc les solutions au travers du PBS).
TSA1049722-02
Copyright © THALES 2012 - E.Tonnellier & O.Terrien
6
Grâce à de multiples ateliers collaboratifs Lean, des implémentations réelles d’arborescences techniques illustreront notre problématique. Les efforts réalisés autour de ces représentations par des disciplines distinctes vers un objectif commun aideront les lecteurs à réfléchir sur ce qui permet aux équipes de développement, de production, de soutien au client… de prêter attention aux spécificités voire
aux difficultés d’autres protagonistes du projet.
Impliquer et fédérer tous les acteurs des projets en R&D autour du PBS témoigneront des opportunités pour réduire des gaspillages inévitables dans les entreprises.
Ce papier adresse plusieurs ‘Lean Enablers for Systems Engineering’ définis par l’INCOSE :
1. Utiliser une description claire de l’architecture de la solution retenue afin de rendre cohérentes
les structures des projets, des ingénieries et des commerciaux. Toutes autres choses égales par
ailleurs, choisir la solution la plus simple.
2. Prévoir l’utilisation d’équipes pluridisciplinaires composées des personnes les plus expérimentées
et compatibles dès le début du projet pour examiner le plus large éventail de solutions possibles.
3. Promouvoir la réutilisation et le partage des acquis des projets. Utiliser des plateformes, des
standards, des bus ou encore des modules que cela soit pour le hardware, le software jusqu’au
savoir. Insister pour que chaque module proposé à l’utilisation soit robuste avant emploi.
4. Prévoir un maximum de continuité dans le personnel s’occupant de l’Ingénierie des Systèmes durant tout le projet.
5. Laisser les besoins en information tirer les activités nécessaires à mener.
TSA1049722-02
Copyright © THALES 2012 - E.Tonnellier & O.Terrien
7
3. PBS & Offres
Durant la phase préliminaire de la conception d’une nouvelle solution, la structuration de cette solution est primordiale. En effet, de l’exploration du concept initial naissent les premiers niveaux d’une
arborescence technique et fonctionnelle, des activités à mener et donc de leurs estimations, les stratégies de partenariat, de sous-traitance, de fabrication, de développement, etc. C’est pourquoi le PBS est
au cœur de cette première partie. Un bref rappel des spécificités du processus offre sera suivi par une
définition et une illustration concrète de cette arborescence technique.
3.1 Processus d’Offre
Dans les domaines Aéronautique & Défense, le processus de réponse à appel d’offre possède diverses spécificités dont la principale est d’être un processus à Tfin immuable. Un jour de retard sur une réponse et tout le travail effectué devient caduque car l’offre remise ne sera pas analysée par le client potentiel. De cette contrainte découlent deux notions : une visibilité restreinte sur certaines sous-parties
de la solution et des actions de dé-risquage sur la solution retenue.
END
START
En temps contraint, il est impossible d’obtenir une évaluation exhaustive, consolidée et sûre à 100%
(sauf à répondre hors délai). L’enjeu pour l’Ingénierie des Systèmes est donc de limiter les risques pris
pour qu’ils ne deviennent pas hors toute proportion lors du projet c’est-à-dire lorsque la société se
trouve entièrement engagée par le contrat. De ce temps contraint, deux impératifs apparaissent :
1) Structurer une solution qui couvre 100% des demandes du client (une voire plusieurs réponses
pour chaque question identifiée) et qui traite de 100% du cycle de vie de la solution (du développement jusqu’au retrait de service). En temps contraint, couvrir tous les sujets bien que tout ne puisse
être couvert dans le moindre détail.
2) Minimiser et confiner les risques pris en détaillant/analysant les zones floues, ambigües ou obscures. Affiner la description des parties les plus critiques afin de limiter à un niveau acceptable les risques pris et de sécuriser la solution retenue d’où la notion de « dé-risquer » l’inévitable incertitude des
processus de conception et de développement. En un mot, sécuriser l’offre.
3.2 Définition du PBS
La définition d’un PBS par la norme ANSI/EIA-632 montre combien cette arborescence technique
est pertinente durant cette exploration des concepts initiaux en phase offre :
“PBS is a hierarchical structure of the complete set of physical systems and subsystems including
operational system, training system, development support, production support, etc which identifies the
configuration items”.
La finalité d’un PBS est donc de structurer la solution en prenant en compte l’ensemble du cycle de
vie de celle-ci (conception, développement, opération, formation, réparation, etc) mais aussi en déterminant les types de ses constituants (par exemple : les prototypes, les moyens d’essais, les constituants
acquis, etc). A partir de cette représentation, il est possible d’estimer le coût global de cette solution
avec une visibilité satisfaisante (par exemple, en fonction de la criticité de certains constituants). Le
PBS permet aussi de définir des stratégies pour le système principal (‘SOI, System Of Interest’ en anglais) ainsi que pour les systèmes pour faire, pour maintenir… (‘Enabling Systems’ en anglais).
TSA1049722-02
Copyright © THALES 2012 - E.Tonnellier & O.Terrien
8
En phase offre, la principale contrainte du PBS réside dans le temps contraint pour le constituer. Le
temps de cette phase étant généralement restreint, le PBS sera initialisé jusqu’à atteindre un niveau de
détails acceptable afin de sécuriser la solution. Acceptable est donc le critère à préciser. Un équilibre
entre le ‘trop’ et le ‘trop peu’ et par conséquent le niveau de visibilité associée deviennent l’enjeu réel
de l’Ingénierie des Systèmes durant cette phase préliminaire des projets.
3.3 Niveaux de visibilité & critères d’arrêt
Eclairer les zones d’ombre, éclaircir les zones en pénombre et confirmer les zones claires sont les
trois activités à mener durant le processus d’offre. Toutefois, en temps imparti, elles ne doivent immobiliser les ressources disponibles qu’au strict nécessaire et donc s’arrêter au niveau satisfaisant pour
réaffecter les ressources sur des zones plus risquées. Quels critères fournir à l’Ingénierie des Systèmes
pour stopper une analyse au moment opportun et réorienter les efforts sur un sujet plus pertinent ? Plusieurs retours d’expérience obtenus au travers de nos interviews précisent le niveau acceptable pour un
sous-ensemble d’un PBS : détailler le PBS jusqu’au moment où l’Ingénierie des Systèmes est capable
d’utiliser un de ses modèles de coût pour réaliser une estimation crédible de la sous-partie étudiée et
pour stabiliser les hypothèses associées. A partir des choix faits sur les réutilisations, sur le respect des
lignes de produits déjà existants, sur les partenariats et sous-traitances, sur les modèles de coûts des
constituants majeurs, l’Ingénierie des Systèmes valorise les risques probables (techniques, financiers,
calendaires, organisationnels, contractuels, etc) et compare la solution retenue avec les précédentes
conceptions similaires (principales dérives observées, instabilité constatée des demandes du client,
etc). Au final, le PBS structure la solution retenue en sous-ensembles majeurs mais définit aussi des
typologies d’activités avec un indice de confiance sur leur réalisation.
3.4 Illustration d’un PBS en phase Offre
La décomposition d’un système est progressive et itérative jusqu’aux critères d’arrêt évoqués précédemment.
Système A
Segment Vol AA
Segment Sol AB
Equipment AAA
Equipment AAB
Equipment ABA
Equipment ABB
NDI
New
New
NDI
IHM AAA
Simulateur
Proto AAB
Banc IVV
Stratégie (Ligne de produit/ re-use / etc)
Cycle de développement
Actions de réduction de risques
Produits « pour faire »
Figure 4: PBS d'un drone en phase d’offre (système de véhicules aériens non habités)
Décomposition et identification des typologies :
Un premier passage permet de décomposer le système en sous-ensembles en identifiant les niveaux
de re-use/ acquisition/ développement ainsi que la maturité des technologies employées (TRL, Technical Readiness Level). Cette première représentation oriente rapidement la stratégie du projet.
TSA1049722-02
Copyright © THALES 2012 - E.Tonnellier & O.Terrien
9
Conformité au besoin et estimation des risques :
Un deuxième passage permet de vérifier la conformité aux besoins exprimés par le client et
d’estimer le niveau de risque pris pour chacun des constituants (y compris les éventuelles actions de
dé-risquage). Après ce second balayage, la représentation est plus complète. Elle montre comment les
différents éléments du système sont constitués et comment l’ensemble peut être recomposé (architecture et planning).
Interdépendance et qualifications :
Un troisième passage détermine les cycles des sous-ensembles à concevoir, les stratégies
‘Team/Make/Buy’, les stratégies de développement et d’IVV (Intégration, Vérification, Validation
avec les moyens d’essais associés) ainsi que l’ensemble des produits pour faire, pour produire et pour
soutenir. Après ce troisième balayage, la représentation identifie les interactions et interdépendances
entre les constituants du système complet.
3.5 Exemple d'atelier Lean Engineering en phase Offre
Dans le cadre d'une compétition pour fournir un système aéroporté basé sur de nouvelles techniques
de détection électromagnétique, une équipe Offre itère sur les versions d'une solution techniquement
prometteuse mais manifestement incompatible avec le budget du client. Afin de réduire drastiquement
son prix, cette équipe envisage deux solutions innovantes mais elle constate très vite l’impossibilité de
comparer les WBS des trois alternatives tant la variabilité entre scénarios possibles est grande. A ce
stade de l’offre, les lacunes dans les dossiers s’accompagnent d’importants risques technologiques.
La situation demande un regard neuf au travers d’une autre approche méthodologique. C'est pourquoi un atelier participatif Lean est organisé avec toutes les parties prenantes (‘stakeholders’ en anglais). Ensemble, elles travaillent sur le PBS des trois solutions envisagées : un moyen d’éviter le blocage dû aux WBS instables ou incertains. La confrontation des points de vue durant cet atelier génère
deux idées principales pour évaluer une solution future. D’un côté, la maturité de chaque constituant et
la combinaison des sous-ensembles pour aboutir à un système complet. D’un autre côté, la criticité de
chaque équipement dans la conception d’une solution globale.
System
Receiver
P-1
1
P-2
R1
2
3
R2
2
4 Maturity
3
R3
4
3
R4
4
1
0
Power
3
F-1
2
F-2
1
4
Fusion
4 Criticity
2
Serv.A 1
0
4
Serv.B 2
2
Servitudes
Serv.C 4
2
Figure 5: Un des trois PBS possibles et chaque influence des sous-systèmes
Une fois les axes de travail clarifiés, les participants établissent des critères pour déterminer les niveaux des deux idées. Une fois les règles définies, les participants pondèrent la maturité avec l’aide
des TRL (Technological Readiness Level) en introduisant un indice proportionnel au saut technologique nécessaire pour chaque constituant. Idem pour la criticité avec l’aide des TNV (Technological
Need Value).
TSA1049722-02
Copyright © THALES 2012 - E.Tonnellier & O.Terrien
10
Si une nouvelle conception est comparée à un long périple, la maturité représente la longueur de
chaque sous-chemin à parcourir alors que la criticité correspond à l'intérêt de suivre chaque souschemin proposé. Grâce à cet atelier, les risques inhérents à chaque alternative sont évalués rapidement
et l’équipe peut définir les actions pour réduire ces risques afin d’atteindre un niveau acceptable au
moment de soumettre l’offre au client.
Criticity
S.C
R2
P-1
F-2
F-2
R3
R1
S.B
P-2
S.A
R4
Maturity
Figure 6: Matrice de risques pour un des trois PBS
Après avoir décliné les WBS et OBS de ces trois PBS sécurisés, l'équipe Offre établit une réponse
pour un futur projet garantissant les coûts et les délais avec un seuil de confiance acceptable.
En phase Offre (BID), le PBS apparaît comme un acte fort de l’Ingénierie des Systèmes. Il
constitue le levier majeur pour structurer une Solution (architectures & cycles de développement). En envisageant la Solution tout au long de son cycle de vie, le PBS dimensionne tout le
projet futur (stratégies & activités).
TSA1049722-02
Copyright © THALES 2012 - E.Tonnellier & O.Terrien
11
4. PBS & Projets
Le contrat est enfin-signé. Par contre, la solution complète n’est pas encore conçue. L’équipe du
projet utilise alors les hypothèses et le PBS initialisé durant la phase Offre. Ce PBS oriente tout le développement : il comprend les articles non développés (‘NDI : Non Developed Item’ en anglais, sousensembles orientés vers les services Achats), les articles matériels et logiciels à développer (‘HWCI et
SWCI, Hardware ou Software Configuration Items’ en anglais, sous-ensembles confiés à des concepteurs Matériel/Logiciel) ainsi que des renseignements sur la validation, la réalisation, la logistique, etc.
4.1 Processus de développement
Dans les domaines Aéronautique & Défense, le processus de développement possède certaines caractéristiques dont la principale est de transformer des informations initiales en enchaînant les prises
de décision. Il s’agit donc d’un processus divergeant car toutes les décisions fournissent une part de
valeur ajoutée à la solution mais, à chaque fois, une nouvelle prise de risques.
decision3
END1
decision1
END2
option1
START
decision2
END3
END..
ENDn
La somme de toutes les décisions ne garantit pas le succès d’un développement car les informations
transformées dépendent souvent les unes des autres. Un exemple fort connu est la fixation de deux
plaques ensemble à l’aide d’une vingtaine de vis. Serrer une vis après l’autre aboutit souvent à
l’impossibilité de fixer la dernière (loi de Murphy oblige). Parvenir à fixer ces vingt vis n’est pas uniquement le résultat de vingt serrages mais aussi l’enchaînement en croix de tous ces serrages. De la
même manière, un processus de développement n’est pas la simple somme de toutes les activités à
mener mais l’accumulation de tâches réalisées avec une vision partagée et un objectif commun.
Cette vision est fournie par le PBS qui tire littéralement les activités de développement vers le produit à livrer, produire, maintenir, etc. Cette arborescence hiérarchise les priorités et permet à tous les
protagonistes du projet de rester concentrés sur l’objectif commun lorsque des choix sont à faire. Elle
évite les divergences que chaque concepteur pris individuellement peut introduire dans le système
global pour satisfaire son optimum local. Cette vision partagée par tous est l’apport majeur de ce PBS
qui assure la convergence de tous les efforts vers l’acceptation du système complet. Toutes les stratégies de développement et d’IVVQ sont prévues en conséquence.
4.2 Arborescence de développement
Basée sur le PBS, l’arborescence de développement est une représentation structurée de la décomposition du système en sous-systèmes et en articles de configuration (‘CI, Configuration Item’ en anglais). Elle prend en compte les caractéristiques fonctionnelles du système en organisant tous les articles de configuration et en reliant entre niveaux tous les liens de traçabilité des exigences spécifiées
(les exigences d’un niveau N sont directement dérivées du niveau N-1). Le dessein de cette arborescence est de supporter les deux états ‘fonctionnel’ et ‘spécifié’ de la solution pendant les activités de
conception et de développement (y compris les phases IVVQ).
TSA1049722-02
Copyright © THALES 2012 - E.Tonnellier & O.Terrien
12
4.3 Articles de configuration & critères de choix
Au moyen d'une approche généralement descendante, progressive et itérative, l’arborescence de développement décompose le système en ses principaux constituants. Une nouvelle fois, la question se
pose quant au niveau de détails et à la complexité de la configuration à gérer. C'est pourquoi cette représentation consiste à identifier les principaux composants et à utiliser l'architecture fonctionnelle,
l'architecture physique du système ainsi que les interactions entre les composants de la solution.
L’Ingénierie des Systèmes alloue les caractéristiques (fonctions, exigences, contraintes) à chacun de
ces éléments. Dans cette représentation, l’article de configuration se révèle être un article particulier
car il doit pouvoir être spécifié, identifié, assemblé, testé et maintenu.
Augmenter le nombre d’articles de configuration (CI) amène une vision très détaillée du système
mais requiert une gestion complexe et rigoureuse. Cette multiplication des CI entraîne une prolifération de la documentation, des revues, etc. D’un autre côté, la diminution du nombre de CI facilite la
gestion de la configuration mais complique la gestion des évolutions. La réduction des CI étend la taille de ceux-ci jusqu’à favoriser la propagation des changements entre articles.
4.4 Illustration d’une arborescence de développement
La construction d’une arborescence de développement démarre d’un PBS et applique des critères de
choix aux articles de configuration comme les niveaux de maturité technologiques (TRL), les constituants communs à plusieurs produits, les co/sous-traitances, les versions prévues, etc.
CI
Système A
SSS & ICD
CI
CI
Segment Vol AA
Segment Sol AB
CI
CI
SSS & ICD
COTS
CI
Equipment AAA
Equipment AAB
Equipment ABA
Equipment ABB
NDI
New
New
NDI
(HW)CI
(SW)CI
IHM AAA
Proto AAB
HRS
Déclinaison documentaire
(SW)CI
COTS
Simulateur
PIDS
Banc IVV
SRS & IRS
CI
Gestion de la configuration
Figure 7: Ajustement d'un PBS pour préparer une arborescence de développement
4.5 Stratégies d’IVVQ
Souvent appelé ‘remontée du V’ dans le classique cycle en V, la séquence ‘Intégration, Vérification, Validation, Qualification’ fait partie du processus de développement. Ces activités prouvent que
le système fonctionne comme prévu : démontrer que le produit est conforme à l’attendu et qu’il s’agit
du produit approprié (« the product is right and it is the right product »). Cela requiert de passer certains jalons et de dépasser des critères d’achèvement du développement. La nature spécifique de ce
sous-processus réside dans ses critères prédéfinis dès le début du développement. La stratégie d’IVVQ
dépend donc du PBS qui structure la solution et de l’arborescence de développement qui précise la décomposition du système à accepter. La maîtrise d’un développement se juge donc à la fin du projet.
L’expérience de ces remontées du V est essentielle pour bâtir des arborescences techniques fiables et
pérennes. Comme le scénario IVVQ implique un certain nombre d'articles et d'incréments, le PBS
structure la planification du projet en introduisant des cycles de vie incrémentaux et/ou en faisant évoluer ses constituants (le cycle en V n’est que théorique et ne résiste pas à la réalité du versionnement
d’un système).
TSA1049722-02
Copyright © THALES 2012 - E.Tonnellier & O.Terrien
13
4.6 Exemple d'atelier Lean Engineering en phase Projet
Dans le cadre d'un projet préparant une phase IVVQ l'équipe d’Ingénierie des Systèmes rencontre
un retard important sur un constituant majeur de sa solution. Une première révision suggère d’élaborer
un simulateur pour remplacer ce sous-ensemble indisponible afin de minimiser les impacts de ce retard
et redonner une marge de manœuvre au projet. Avec cette substitution, les modèles de coûts habituellement utilisés par l’équipe deviennent inapplicables. Par conséquent, un atelier collaboratif Lean est
organisé avec toutes les parties prenantes afin d’envisager toutes les alternatives pour respecter le calendrier de livraison et tenir les engagements financiers.
Les travaux de l’atelier sont orientés vers le PBS (le ‘quoi’) afin de permettre à tous les participants
de visualiser les impacts des suggestions sur leur propre livrable. Rendre visibles les effets du problème permet à toutes les disciplines de s’associer aux propositions et de vérifier leurs adéquations avec
le reste de la solution. Seules les propositions techniquement valides sont déclinées en activités à réaliser et estimées pour modifier le WBS initial du projet (le ‘comment’ du scénario alternatif). Grâce aux
nombreuses idées palliatives, un simulateur est confirmé pour se substituer à l’élément manquant.
Figure 8: Afficher les impacts pour proposer des solutions adéquates
Masquer une fonction indisponible en émulant des interfaces réalistes neutralise un risque majeur :
un nouveau sous-système facilitant (‘Enabling System’ en anglais) positionné au niveau adéquat dans
le PBS de la solution. L'équipe du projet réorganise en conséquence ses livrables et ajuste sa stratégie
IVVQ en ajoutant un incrément rendu nécessaire pour la double étape ‘SOI & Simulateur’ puis ‘SOI
complet’.
Au démarrage d’un projet, le PBS apparaît comme un levier d’ajustement majeur pour
l’Ingénierie des Systèmes. Il constitue la vision partagée qui fédère tous les efforts et qui oriente
toutes les décisions vers un objectif commun : le succès de la solution développée.
TSA1049722-02
Copyright © THALES 2012 - E.Tonnellier & O.Terrien
14
5. PBS & Productions
De nombreuses parties prenantes sont impliquées dans la constitution d’un PBS. Un des principaux
utilisateurs du processus de développement permet d’introduire une arborescence supplémentaire.
5.1 Processus de production
Le processus de production possède la spécificité de reproduire une configuration approuvée et
d’assembler les constituants d’un système dont les interactions ont été précédemment validées. Il
s’agit donc d’un processus récurrent qui aboutit à des répétitions.
END
START
START
END
START
END
Un état initial du système, c’est-à-dire approuvé, peut subir des modifications : l’état défini du système est l'état initialement approuvé puis complété de toutes les évolutions dûment acceptées. Cette
définition et cette acceptation constituent deux enjeux majeurs du processus de production. En effet,
ces deux notions garantissent l’interchangeabilité des constituants du système au delà du simple bon
fonctionnement de chacun de ces éléments. Pour assurer une cohérence tout au long du cycle de vie
d’une solution, le PBS présente une vision partagée aussi bien pour le système principal que pour les
systèmes facilitants (‘Enabling Systems’) pour faire, pour réparer, pour modifier, etc.
5.2 Arborescence de définition
Déduite de l’arborescence de développement (‘Development Breakdown’ en anglais) sans la remettre en cause, l’arborescence de définition (‘Design Breakdown’ en anglais) est la représentation structurée de tous les articles d’un système. Elle traduit les caractéristiques physiques du système en structurant les articles mais aussi les documents de définition qui permettent de reproduire à l’identique
plusieurs exemplaires. Les liens entre les niveaux de cette représentation traduisent les liens
d’assemblage (l’article du niveau N entre dans la décomposition du niveau N-1).
Les deux arborescences de développement et de définition sont deux représentations d’un même
système. Elles n’ont pas la même finalité mais ne sont pas indépendantes l’une de l’autre puisque
l’une est déduite de l’autre. Les activités et décisions au cours de la construction de la première ont
donc un fort impact sur le second.
5.3 Arborescence logistique & critères d’échange
Dans l’arborescence de définition se pose la question d’échange d’un constituant et de l’impact
d’une évolution sur le reste du système complet. A la fois échangeables et réparables par le client en
intervertissant leurs constituants, ces articles se distinguent par leur niveau d’intervention :
URA, Unité Remplaçable en Atelier (‘SRU, Shop Replaceable Unit’).
URL, Unité Remplaçable en Ligne (‘LRU, Line Replaceable Unit’).
Ces composants logistiques ne seront pas forcément des CI, mais ils peuvent apparaître en tant
qu’articles suivis dans leurs différents états de configuration. Les composants logistiques susceptibles
d’être articles de configuration doivent posséder un certain niveau de complexité.
TSA1049722-02
Copyright © THALES 2012 - E.Tonnellier & O.Terrien
15
5.4 Illustration d’une arborescence de définition
La construction d’une arborescence de définition part de l’arborescence de développement et applique des critères de sélection des articles de configuration (CI).
CI A
ART X
CI B
ART Y
CI C
Arborescence de développement
ART Z
Arborescence de définition
Figure 5 : Visibilité entre les arborescences de développement et de définition
5.5 Exemple d’un atelier Lean en Support Client
Dans le cadre d'un système en service, une équipe Support Client découvre l’obsolescence d'un
composant programmable du système. Les premières investigations techniques sur les impacts potentiels montrent l'existence d'un équivalent physique interchangeable : aucune modification autre que le
remplacement d’une référence dans l’arborescence de définition du produit. Cependant, l’équipe Support Client alertée par une précédente expérience décide de détailler l’analyse au travers du PBS du
système. Cette investigation approfondie montre un effet de bord de la substitution sur les moyens de
programmation et sur les procédures du client. Les nouvelles versions du logiciel embarqué dans le
composant ne pourront plus être téléchargés avec les outils informatiques disponibles chez le client.
Grâce à la prise en compte des moyens pour faire ou pour maintenir (‘Enabling Systems’), l’équipe
évite une importante insatisfaction de son client. Elle décide d’ajouter une verrue physique sur le prochain lot de circuits imprimés afin de souder un composant programmable similaire à celui désormais
obsolète, composant proche, différent physiquement mais qui utilise les même outils de programmation que le précédent. Cette analyse habile du PBS du système minimise les perturbations des activités
logistiques réalisées par l’équipe Support Client.
Un document de la NASA illustre le rôle du PBS :
« Architecture et conception doivent décomposer le système complet en ses sous-ensembles majeurs
afin de former la hiérarchie de toutes les spécifications et interfaces des niveaux inférieurs du système »
Durant les phases de production et de soutien, le PBS maintient les décisions pour faire et
pour maintenir dans la vision partagée d’un système complet et cohérent.
De l’offre au retrait de service, toutes les phases sont tirées vers un objectif commun par un
PBS dont le rôle doit être renforcé et maintenu tout au long du projet.
TSA1049722-02
Copyright © THALES 2012 - E.Tonnellier & O.Terrien
16
6. Conclusion
En conclusion,
Le PBS (Product Breakdown Structure) est un levier majeur de l’Ingénierie des Systèmes.
Durant les phases d’offre, de développement, de production et de soutien au client, le PBS représente le phare qui dirige toutes les décisions et les arbitrages, qui éclaire les situations obscures
et qui fédère les efforts de l’ensemble des disciplines impliquées dans l’Ingénierie des Systèmes.
7. Bibliographie
[1] TERRIEN Olivier, “INCOSE 2010: The Lean Journey”
http://www.thalesgroup.com/Lean_Engineering_Incose2010.aspx
[2] OPPENHEIM Bo, “INCOSE 2010: WG Lean for SE”
http://cse.lmu.edu/about/graduateeducation/systemsengineering/INCOSE.htm
[3] OPPENHEIM Bo, “Lean for Systems Engineering; with Lean Enablers for Systems Engineering”, 2011
[4] SAUSER Brian, “Incose2009: Defining an Integration Readiness Level for Defense Acquisition”
[5] NASA/NPR 7120.5, Space Flight Program & Project Management Handbook (Feb.2010)
[6] NASA, Work Breakdown Structure Reference Guide (May 1994)
[7] NASA/SP-2007-6105, Systems Engineering Handbook (Dec.2007)
[8] NASA/GPG 7120.5, Systems Engineering (2007)
[9] DoD/MIL-STD-881C, Work Breakdown Structures for Defense Materiel Items (Oct 2011)
[10] DEF(AUST)5664 Issue A, Work Breakdown Structures for Defense Materiel Projects
[11] AFIS-CTMIS-PROJET MIS06, Maîtrise des interfaces : une affaire de technique & projet
8. Remerciements
A Séléna BESSOT pour cette version française.
A Anne SIGOGNE pour ses contributions expertes et ses précieux conseils.
TSA1049722-02
Copyright © THALES 2012 - E.Tonnellier & O.Terrien
17
9. Auteurs
Edmond TONNELLIER
Expert System Engineering
Fort de ses années consacrées aux développements de produits complexes, Edmond Tonnellier anime aujourd’hui les processus d’Ingénierie des Systèmes de Thales Systèmes Aéroportés et participe
aux rédactions de la méthodologie Système du groupe Thales (‘SysEM Handbook’ et ‘Corporate Guide – Value Analysis’). Evaluateur CMMI SEI DEV & ACQ, il mène de nombreux audits dans et hors
du groupe Thales. Il complète ce rôle de référent par une contribution régulière aux formations IS de
l’Université Thales et par les nombreuses sessions qu’il dispense.
Membre AFIS et INCOSE (certifié CSEP, relecteur BKCASE)
Ingénieur, 1977, ISEP, France
Olivier TERRIEN
Expert Lean Engineering
Expert Lean pour Thales Systèmes Aéroportés, Olivier Terrien déploie la démarche Lean Engineering dans l'Ingénierie des Systèmes, le développement logiciel et matériel ainsi que dans la conduite de
grands projets. Son expérience professionnelle provient de la conception de composants hyperfréquences, du développement de cartes électroniques et de l'intégration, vérification, validation de nombreux
systèmes électroniques aéroportés. Son expertise se complète de nombreuses conférences données en
université et par plus de 350 pages publiées dans la presse internationale.
Membre AFIS et INCOSE
Ingénieur, 1997, ESEO, France
MBA, 2006, IAE Paris-La Sorbonne, France
A télécharger sur le site :
http://www.thalesgroup.com/PBS_Product-Breakdown-Structure_CSDM2012.aspx
TSA1049722-02
Copyright © THALES 2012 - E.Tonnellier & O.Terrien
18