! !
Value&Driven,Design,&,A,methodology,to,Link,Expectations,to,
Technical,Requirements,in,the,Extended,Enterprise,
"#$!%&$'&&()
*
+!,$-.(!/(&&0$))
1
+!,$-2(!34-5().
6+7
+!8$''.!9-4&
:
+!;))4!,()24$<=
>
+!;#4&&$)?-(!34-5().
7
+!
@54A4!B.&4$##
C
+!D.)E4.!FG$)H
I
!
*
J/K!;4-(&L$24!9)H.)4!@M&540&!@E4?4)!N"#$O%&$'&&()PH')$4-(&L$24O2(0Q!
1
;%R3S@!N,$-.(O/(&&0$))P$.-T<&O2(0Q!
6
3#4'.)H4!%)&5.5<54!(U!V42G)(#(HM!N0$-2(OT4-5().PT5GO&4Q!
7
W<#4X!S).A4-&.5M!(U!V42G)(#(HM!N0$-2(OT4-5().P#5<O&4+!$#4&&$)?-(OT4-5().P#5<O&4Q!
:
S).A4-&.5M!(U!@(<5G$0L5()!N8$''.O9-4&P&(5()O$2O<'Q!
>
9;Y@!%))(A$5.()!B(-'&!N;))4O,()24$<=P4$?&O)45Q!
C
R(##&ZR(M24!L#2!N@54A4OB.&4$##P-(##&Z-(M24O2(0Q!
I
S).A4-&.5[!?4!V(<#(<&4!N=E\G$)HP45<?O.)&$Z5(<#(<&4OU-Q!
,
Copyright,©,2013,by,the,authors.,,Publishe d ,a n d ,u se d,by,INCOSE,w i th ,p e r mission.,
Abstract. Current systems engineering (SE) standards do not address ‘Value’ in much detail.
Yet, understanding what drives the generation of stakeholder value in a given business
context, is fundamental to promoting a common and clear vision throughout the extended
enterprise, of what should be the focus of their early, conceptual work at all levels of
development. This paper presents a Value-Driven Design (VDD) methodology designed to
strengthen the value and requirements maturation process within an extended enterprise
setting. The work presented is the result of a three and a half year European program
(CRESCENDO) within the aerospace sector. The VDD methodology is introduced and
explained in an industrial aircraft development context and a selection of enabling methods
and tools associated to the VDD methodology is presented.
Introduction and Background
Traditionally, the basis for any work at any level of this extended enterprise would be the
technical requirements, which are signed off as part of the respective contracts between
directly interfacing partners within the extended enterprise. However, there are strong
pressures to develop ever faster, better and cheaper. In order to respect the short development
schedules within aircraft development programs, organizations tasked with the development
of long lead items, such as the aircraft engines or the landing gears, have to start working a
long time before mature aircraft requirements are made available to them.
Such organizations traditionally have a number of options regarding how they could deal
with such a situation: (1) they could wait and only start working after they have received their
validated input requirements from the top level; (2) using previous experience and a number
of assumptions, they could start working at their level, without exactly knowing what their
input requirements will be; or (3) they could ask for preliminary versions of their input
requirements in order to start their work based on those.
! !
The above options have some serious drawbacks. Option (1) means that these organizations
will work on a sound basis, but won’t have much time to develop their long lead items, i.e.
this option could result in delays for the overall aircraft program. Option (2) would be much
riskier and prone to corrective rework, which could lead to unplanned costs and delays. Also,
this would potentially lead to conservative rather than innovative design solutions. Option (3)
would imply a high degree of risk, too, as the development efforts would be based on
immature input requirements, invariably leading to high levels of corrective rework, which in
turn will lead to unplanned costs and delays, as well as conservative rather than innovative
design solutions. In addition, even as requirements has been decomposed and validated, there
still remain a risk of misconception and delay due to the simple fact that requirements need to
be interpreted, and their context understood. Since aircraft requirements are typically
cascaded several times before being available by sub-system manufacturers, retaining their
governing intent and rationale is by nature difficult.
The objective of the paper is to present a Value Driven Design (VDD) methodology,
developed within an EU FP7 project in aeronautics named “Collaborative and Robust
Engineering Using Simulation Capability Enabling Next Design Optimisation”
(CRESCENDO, 2012), which targets the need for design iterations to be executed in the very
beginning of an aircraft development program. The aim of the proposed methodology and
associated support tools is to support the requirements establishment process and strengthen
the value contribution focus into the development organization. This is expected to reduce
development risks and corrective rework considerably.
The Value-Driven Design Methodology
The Value-Driven Design (VDD) methodology proposed in the paper aims to complement
traditional systems engineering (SE) processes (INCOSE, 2011) by using the concept of
value for early design concepts generation and selection. The methodology is inspired by
previous VDD approaches proposed in literature (Castagne et al., 2009, Collopy and
Hollingsworth, 2011) and aims to enable what-if assessment loops to be executed at all levels
of the supply chain in the very early stage of the aircraft design process, well before detailed
requirements are made available by the aircraft manufacturer. Compared to previous work in
INCOSE (Roedler et al., 2005), the proposed framework adopts an information driven
approach that link customer expectations to characteristics and enabling value fulfillment as
drivers for design within an extended enterprise through iterations.
The Value Creation Strategy (VCS) is the entity (or document) that carries preliminary
design information across the supply chain partners, and enables their teams working on long
lead items to initiate the development work earlier than what happens today. A VCS is a
description of a specific context for a project. Initially, it includes a set of rank-weighted
needs that have to be satisfied for identified stakeholders or customer profiles. In later
iterations it also encompasses a list of rank-weighted objectives with corresponding
measurement criteria and a set of Value Drivers (VDs). VDs indicate key engineering
characteristics given a specific VCS (i.e. for a specific stakeholder profile and context). They
represent solution directions that seem to have a significant influence on the value perceived
by the customer (or by the stakeholders) in a given problem context. VDs are not attached to
a target value or function, but they tend to result in measurable objectives and later, based on
these, in requirements. The VDD methodology follows a series of linked activities, tailored to
facilitate iterations (Figure 1):
! !
Figure 1. High level Value-Driven Design process
The first step (1) deals with capturing and validating stakeholder expectations, which are then
organized and interpreted in terms of needs, which are further rank-weighted on the base of
their importance for a given context (2), such as the low-cost carrier market segment that the
aircraft program aims to target. A first VCS is developed for the given context (3) and
contains a context description, the rank-weighted needs for the context and a list of suggested
VDs (essentially, system characteristics that are expected to particularly contribute to
stakeholder value). Later in the development cycle, a hierarchy of Quantified Objectives
(QOs) with specific target values or target functions is identified for each rank-weighted need
(4). Given this input, a second VCS iteration can be developed (5), containing a refined
description of the context and of the VDs for the study. It also contains an optimum selection
of QOs that represent design concepts or solutions that have been recognized to satisfy the
targeted stakeholders’ needs. This loop helps to increase confidence that the business case in
terms of the retained set of objectives is sound, and that the proposed concepts or solutions
are achievable.
The VCS is then used as input to perform optimization of early design concepts at different
levels of the supply chain (6), using a range of approaches as described in the following
sections. Once the most value adding design concepts are identified, requirements are
established based on the rank-weighted QOs (7) and can be communicated in a third iteration
VCS, which summarizes the updated context information and makes reference to the
validated requirements.
The extended enterprise view of the VDD methodology
Within the extended enterprise, the VCS can be collaboratively built much earlier than is the
case where merely a traditional approach to Requirements Management is deployed (see
Figure 2), and can be more easily communicated from one level to the next (Monceaux and
Kossmann, 2012). The aircraft level VCS description, which contains high-level information
on frame, power-plant and cabin design, is initially cascaded down to engine level. The
engine manufacturer uses the VCS, together with other information, to rank-weight engine
needs. The description of the rank-weight engine needs is added to the VCS, and is cascaded
further down to the engine sub-system level, and so on.
! !
Figure 2. VDD enhances traditional RM within the extended enterprise
Figure 3 and Figure 4 exemplify how two aircraft level needs are cascaded down in the
supply chain and how they can be re-elaborated locally by the partners.
- Need 1: ‘To be known for passengers first.’
- Need 2: ‘To be the most fuel efficient.’
Figure 3. Translating Value Drivers from one level to the next (Comfort),
! !
In Figure 3, the need ‘to be known for the passengers first’ is translated at aircraft level in
three main VDs, such as ‘cabin air quality’, ‘cabin noise level’, and ‘seat spacing’. Of course,
there could be additional value drivers such as ‘cabin lighting’, ‘vibration level’, or more
detailed value drivers, e.g. ‘leg room’ and the ‘texture of seat surfaces’. The initial selection
of the value drivers at A/C level can be communicated in a first iteration of the VCS to the
engine level. The ‘cabin noise level’ VD can be translated, into more detailed drivers at
engine level, such as ‘engine noise level’ regarding air transmitted noise, and ‘engine
vibrations’ regarding structure transmitted noise. Furthermore, they are cascaded one level
down and further characterized by the sub-system manufacturer.
Figure 4. Translating Value Drivers from one level to the next (Fuel efficiency)
In Figure 4 the need ‘to be the most fuel efficient’ is translated at aircraft level in three main
VDs, such as ‘aircraft weight, ‘air drag’, and ‘fuel consumption’. Also in this case, the VDs
can be re-used from one level to the next in the cascade. This initial selection of VDs at
aircraft level can be communicated in a first iteration of the VCS to the engine level. The
‘aircraft weight’ driver can be related to ‘engine weight’, and, further down in the supply
chain, to ‘sub-system weight’.
The VDD methodology in detail
Figure 5 provides a high level view of the simplified VDD process across three example
levels of development in the extended enterprise, the aircraft, engine, and sub-system level.
These levels are simplified, for instance, the aircraft level comprises at least the aircraft
program, the aircraft and the cabin and cargo levels. These levels have been selected to
demonstrate how the VDD process could work within the extended enterprise.
