the application of vsm to npd
TRANSCRIPT
POLITECNICO DI TORINO
Collegio di Ingegneria Gestionale
Corso di Laurea Magistrale
In Engineering and Management
Tesi di Laurea
The application of Value Stream Mapping to New
Product Development
Relatori:
Prof. Paolo Neirotti
Prof.ssa Francesca Montagna
Candidato:
Edoardo Bruno
Anno Accademico 2015/2016
1
To Beppe, Letizia, Mariangela and Renato
2
Table of contents
Introduction ................................................................................................................................................................. 6
CHAPTER 1 ................................................................................................................................................................. 10
1.1 VSM applied to New Product Development ....................................................................................... 10
1.1.1 Application boundaries ..................................................................................................................... 10
1.1.2 Factory versus development processes ...................................................................................... 12
1.2 The followed methodology...................................................................................................................... 14
1.2.1 Identifying key stakeholders ........................................................................................................... 14
1.2.2 Framing the problem ......................................................................................................................... 15
1.2.3 Defining the Value ............................................................................................................................... 16
1.2.4 Process breakdown and data collection ..................................................................................... 17
1.2.5 Waste and improvements identification ................................................................................... 20
CHAPTER 2 ................................................................................................................................................................. 24
2.1 Problem definition ....................................................................................................................................... 24
2.1.1 Process identification ......................................................................................................................... 24
2.1.2 Component definition ........................................................................................................................ 27
2.2 Application of VSM methodology to the case study........................................................................ 30
2.2.1 Stakeholders identification and process bounding ................................................................ 30
2.2.2 Value definition .................................................................................................................................... 31
2.2.3 Process breakdown ............................................................................................................................. 32
2.2.4 Data collection ...................................................................................................................................... 35
2.2.5 Summary of results ............................................................................................................................. 38
2.3 Proposed improvements ........................................................................................................................... 41
2.3.1 Pre-SoCo and Soco improvements ................................................................................................ 42
2.3.2 Technical specifications form ......................................................................................................... 51
2.4 The improved process (TO-BE) .............................................................................................................. 52
CHAPTER 3 ................................................................................................................................................................. 56
3
3.1 The mathematical model ........................................................................................................................... 56
3.1.1 Activity In-process time PT(k) and Rework time RT(k)....................................................... 57
3.1.2 Activity Total Process Time TPT(k) ............................................................................................. 58
3.1.3 Activity Elapsed Time ET(k) and Rework Elapsed Time RET(k) ...................................... 58
3.1.4 Activity Total Elapsed Time TET(k) ............................................................................................. 58
3.1.5 Step Total Elapsed Time STET(i) ................................................................................................... 59
3.1.6 Total Process Elapsed Time (TPET) and resources utilization µ ...................................... 60
3.2 Application of the model to Sourcing Process .................................................................................. 61
3.2.1 AS-IS process ......................................................................................................................................... 61
3.2.2 TO-BE process ....................................................................................................................................... 62
3.2.3 Analysis of results ................................................................................................................................ 64
3.2.4 Model limitations ................................................................................................................................. 65
3.3 Analysis of improvements ........................................................................................................................ 66
3.3.1 Light process introduction ............................................................................................................... 69
3.3.2 One Page introduction ....................................................................................................................... 70
3.3.3 Technical specifications form introduction ............................................................................... 71
3.3.4 Overall improvements impact ........................................................................................................ 71
3.4 The simulation model ................................................................................................................................. 72
3.4.1 AS-IS process simulation .................................................................................................................. 76
3.4.2 TO-BE process simulation ................................................................................................................ 77
3.4.3 Value Added, NVA and waiting times .......................................................................................... 80
Conclusions ................................................................................................................................................................. 83
Bibliography ............................................................................................................................................................... 86
ANNEXES ..................................................................................................................................................................... 87
ANNEX I: One Page Template (Pre-SoCo and SoCo) ......................................................................... 87
ANNEX II: Functional specification form ............................................................................................... 88
ANNEX III : Application of the mathematical model to the AS-IS process................................ 89
4
ANNEX IV : Application of the mathematical model to the TO-BE process ............................. 90
ANNEX V : Arena model for AS-IS process ............................................................................................ 91
Index of figures
Figure 1 PDVSM applies to a definable process within the PD value stream ................................... 11
Figure 2 PDVSM focuses on core engineering processes ......................................................................... 11
Figure 3 Bounding the problem to which PDVSM will be applied ........................................................ 15
Figure 4 Process value questions ....................................................................................................................... 16
Figure 5 Value creation .......................................................................................................................................... 17
Figure 6 Scheme of the Product Development Process ............................................................................. 24
Figure 7 Maximum timings between Sourcing process Milestones ..................................................... 27
Figure 8 Main components constituting the DMF ....................................................................................... 28
Figure 9 Bounding the process .......................................................................................................................... 31
Figure 10 AS-IS Sourcing process scheme ...................................................................................................... 33
Figure 11 Data collection questionnaire ......................................................................................................... 36
Figure 12 Data collection sheet legend ............................................................................................................ 37
Figure 13 Evaluated AS-IS Purchasing process value stream ................................................................. 41
Figure 14 TO-BE Sourcing process scheme ................................................................................................... 53
Figure 15 Maximum Pre-SoCo waiting times AS-IS vs TO-BE ................................................................ 70
Index of tables
Table 1 Applying the five lean steps to Product Development processes ......................................... 13
Table 2 Aspects of value in Product Development tasks .......................................................................... 18
Table 3 Process mapping symbols .................................................................................................................... 19
Table 4 Information wastes ................................................................................................................................. 23
Table 5 Evaluation of “buy” components ........................................................................................................ 29
Table 6 AS-IS Sourcing Process breakdown .................................................................................................. 34
Table 7 Identificaton of Light components .................................................................................................... 45
Table 8 TO-BE Sourcing process breakdown ................................................................................................ 55
Table 9 Model associations for AS-IS and TO-BE Sourcing process ..................................................... 63
Table 10 AS-IS activity - proposed improvement correspondence ...................................................... 67
Table 11 Impact of proposed improvements on process activities...................................................... 68
Table 12 ∆𝑻𝑬𝑻 and ∆𝑻𝑷𝑻 calculations ........................................................................................................... 68
5
Table 13 Simulation Timings AS-IS ................................................................................................................... 74
Table 14 Simulation Timings TO-BE................................................................................................................. 75
Table 15 ∆𝑻𝑬𝑻𝒌𝒂𝒅𝒋 calculations ...................................................................................................................... 80
Table 16 Identification of Value added, NVA and waiting time for AS-IS process .......................... 81
Table 17 Simulation results in terms of VA, NVA and Waiting times .................................................. 82
Table 18 Time performance indicators ........................................................................................................... 82
6
Introduction
This Master thesis deals with the exploration of how the set of techniques and tools known as
Value Stream Mapping can be applied to a particular category of processes inside companies,
that are, the ones related to New Product Development.
The reasons why this topic has been addressed are multiple, and will be detailed below.
First of all, several researches and studies paint a clear picture of current planning practices
for engineering and development processes inside companies. Formal processes are required
for almost all the activities to satisfy quality, safety, regulatory concerns, and to allow
management of complex systems, which require the interaction among several actors, often
physically located in different places in different countries, facing a lot of different kind of
constraints. On top of all, a consistent work overload of resources determines great problems
in terms of timings. That’s because, today, it has become a commonplace, for almost every
company that develop products/services, to organize the work based on projects: this means,
on one side, a better definition of tasks, roles, assignments, but, on the other side, a great
commitment on deadlines and milestones is required.
Inside any company, several processes have been put in place, becoming the “standard way”
for performing the various day-by-day activities: the issue is that these processes are often
poorly defined; existing process definition can refer to obsolete practices, contain detail that is
not relevant to most jobs, or miss key practices (e.g. appropriate ways to handle new
materials or technologies). They may also capture practices that were critically important, but
have become irrelevant over time – in lean terms, they may be monuments.
This situation has a high potential for process inefficiency; to provide an example, the
Massachusetts Institute of Technology, some years ago, has made a research study in the field
of engineering product development processes: engineers were asked to assess how much of
their effort was spend adding value directly to the tasks at hand, how much time was sent in
necessary support tasks, and how much time was wasted. Forty percent of their effort was
described as pure waste, and only thirty percent as value added. In parallel, data collected
from another formal study confirms that 30%-40% of effective work inside a product
development process or sub-process is typically wasted1.
This result, of course, pushes in a totally opposite direction if compared to the common
spread tendency to work by Projects: several planning tools and techniques have been
1McManus et al., Lean Engineering: Doing the Right thing Right, Massachusetts Institute of Technology, 2005.
7
developed and successfully applied, and they allow the Project Manager and its team to
coordinate the set of interacting activities and work packages. In projects relatively easy, with
a short duration, simplified programming can be used, such as Gantt diagrams, where the bars
do not represent connections due to dependency bonds, but only indicate the duration of each
single activity. Complex projects with long duration, where the single activities are connected
by different kind of bonds, and many checks are required, are most suitable to be managed
through planning techniques using network diagrams (such as CPM,PERT or DPM).
Such techniques are very effective in managing the variability associated to process activities,
determining the minimum time in which the project can be completed, and to individuate
critical operations and paths even in complex networks, in order to identify where process-
time improvements can have the highest benefits in terms of overall completion time; in other
words, these techniques mainly focus on planning and controlling processes.
The focus of this study will rather be on Value Stream Mapping, since it is more suitable for
taking into account and identify the value embedded in the process itself, with the purpose to
identify possible improvements that lead to a process that is efficient in terms of value added
and waste reduction. Value added and waste will be detected and measured thought the
exploitation of the know-how of the resources involved in the process itself: they will be
asked to provide their feedback on a set of value and waste parameters (through specific
interviews), such as a qualitative evaluation of major value and waste attributes associated to
each activity they perform inside the process, and also a quantitative assessment of Value-
Added and Non-Value Added times. This will lead to the identification of many improvement
areas within the process itself and, subsequently, to the elaboration of ad hoc process
modifications. In order to assess the effectiveness of the improvements proposed, a
quantitative model will be built so that, starting from the data collected by Value Stream
Mapping, it is possible to calculate some key performance indicators, drawing the appropriate
considerations.
Accordingly to what discussed above, the objective of this Thesis is to develop a mathematical
model that starts from a few, simple process data, collected through the application of Value
Stream Mapping techniques, which are:
In-process times: time that the resource associated to a certain activity of the process
spend to complete the activity itself;
8
Rework Process times: time that the resource associated to a certain activity of the
process spend to complete the activity itself in case of rework;
Rework probabilities associated to each single activity of the process;
Waiting times: time a component flowing into the process has to wait before starting a
certain activity.
Starting from the data previously mentioned, the model should be capable to measure the
performance of the improvements which have been identified through the application of VSM.
Other features required to the model are:
To take into consideration that different “entities” flow into the process with different
values of the abovementioned variables, eventually following different paths;
To take into account that different activities can be performed in parallel by different
resources, according to the level of process breakdown;
To estimate the total time to complete the process under analysis (what will be defined
as Total Process Elapsed Time – TPET);
To estimate the total time each resource is involved in the process, and the associated
utilization factors;
To easily adapt to any specific feature and requirement of the process under analysis.
Once the model is defined and its features and drawbacks illustrated, simulation is introduced
in order to get some evidences on the aspects that cannot be modeled through the formulas.
Furthermore, the simulation will also be useful in order to assess the benefits brought by
proposed improvements in terms of Non-Value Added and Waiting Times reduction.
In order to reach the objectives we set before, a structured investigation process will be
followed. To start with, a literature review on the most common methods and planning
techniques has been done. After that, an introduction to the Value Stream Mapping tools and
techniques applied to New Product Development is necessary, in order to get the required
“background” to switch to a real case application, and to design a methodology capable to get
the correct data and information needed. The application boundaries of a real case study have
to be identified and discussed, then the VSM will be applied to the AS-IS configuration, with
the aim to individuate some improvement proposals based on the results collected with the
previous step: this will lead to the definition of the improved TO-BE configuration.
9
After the application of VSM, the focus will switch to the building of the model, and the
identification of the limitations with respect to the objectives set for this study. Simulation
will then be applied to both the AS-IS and TO-BE configurations, results will be analyzed and
compared to the ones previously got from the mathematical model. Lastly, simulation will be
exploited to get information on Non-Value Added and Waiting Times reduction lead by the
adoption of the improved TO-BE process configuration.
The structure of this Thesis it is organized into three chapters.
Chapter 1 is a theory focus on Value Stream Mapping application to New Product
Development processes, with the individuation of the various steps that have to be followed
inside a real case study application framework, and the definition of fundamental concepts of
value and waste.
Chapter 2 is dedicated to the application of VSM analysis to a real case study: the New
Product Development process inside an automotive company. The problem is clearly defined,
and study boundaries pointed out. The AS-IS process configuration is detailed, VSM is applied,
and a deep focus is provided on which and how possible improvements can be proposed
based on the analysis of results coming from VSM application, leading to the TO-BE
configuration.
Chapter 3 will be totally dedicated to the building of a model, starting with the definition of
the performance measures involved and the step-by-step introduction of the formulas. Then,
the model is applied to both process configurations, results are analyzed, and the main model
limitations are pointed out. Before moving to simulation, an entire section will be dedicated to
the quantitative assessment of the benefits brought by each proposed improvement in terms
of resource workloads and overall process duration. Then simulation is introduced and
applied to both AS-IS and TO-BE process configurations and the output is compared with the
results got from the mathematical model. In the end, last section highlights the effects of the
proposed improvements in terms of Value-added, Non-value added and Waiting times.
10
CHAPTER 1
1.1 VSM applied to New Product Development
One of the best and commonly adopted lean practices to factory processes is the Value Stream
Mapping, a technique used to document, analyze and improve the flow of information or
materials required to produce a product or service for a customer, taking as a key metric
value adding times and non-value adding times. A value stream map is typically created as a
one-page flow chart depicting the current production path or design path of a product from
the customer's request to delivery. An important goal of value stream mapping is to identify
processes that do not provide value so they can be improved. In lean production, value can be
thought of as anything the customer is willing to pay for; processes that do not provide value
are called waste. Value stream maps document the current state (AS-IS) of the value stream as
well as the future state (TO-BE) of the value stream and define any gaps between the two.
Value stream mapping is often used to discover processes that could be streamlined and areas
of waste that could be eliminated in keeping with Toyota's kaizen philosophy, which has been
adopted by many other industries outside manufacturing.
1.1.1 Application boundaries
One of the scopes of this work is to explore Vale Stream Mapping in order to define and
improve a single, definable process inside the general product development context.
Indeed, as Figure 1 shows, every company that develops products/services for a customer
follows its own processes, that can be seen as a Value stream. Those processes are made of
several, different sub-processes, that can be further decomposed into individual tasks or
activities, performed by different resources. The objective is to illustrate a method that can be
applied to many different off-the-factory-floor processes, that will be called “engineering
processes” in order to highlight the fact they contribute to develop new product/processes: it
will be called Product Development Value Stream Mapping (PDVSM).
11
Figure 1 PDVSM applies to a definable process within the PD value stream
At the highest definition level, Lean Engineering can be defined as the set of practices and
tools that pursue three goals:
Creating the right products – creating product architectures, families, and designs that
increase value for all the enterprise stakeholders;
Effective lifecycle and enterprise integration – using lean engineering to create value
throughout the product lifecycle and the enterprise;
Efficient processes – applying lean thinking to eliminate wastes and improve cycle time
and quality in engineering.
PDVSM is a tool for the last goal: achieving an efficient process. It can be an important enabler
for the other goals, but the sole focus of this work will be on process improvement. Figure 2
shows a conceptual view of the entire product development process2:
Figure 2 PDVSM focuses on core engineering processes
2 Adapted from Ulrich and Eppinger.
12
The focus here is on the processes involved in the core phases, such as preliminary and
detailed design, analysis, process design, review, validation and verification. The “front end”,
where user needs are collected and requirements set, has its own problems and may well
benefit from lean analysis. The transition to production is also very important, and is a key
area where enterprise integration is required. These phases will certainly benefit from lean
processes, and may well be targets for value stream improvements, but we will not address
special circumstances and needs of these phases.
The first objection to the application of lean techniques developed in the factory to
engineering development processes is that “engineering is different”. This is true, but it is not,
however, a reason to reject lean as a method for engineering process improvement.
1.1.2 Factory versus development processes
Engineering processes differ in fundamental ways from factory processes. Most of the
differences are driven by the fundamental uncertainty of product development processes – at
the beginning of the process the exact content of the output is not known. This is in contrast
with factory operations, where the ideal is to make a part precisely the same as the last one.
The product development process is also acting upon information more than physical material
– the ultimate output is the specification of a product rather than the product itself. Finally,
most product development processes are acting on a mix of jobs, of greater or lesser difficulty
or complication. This is not a fundamental difference; it is analogous to a factory working on
mixed-model production. It does, however, complicate the application of process
improvements.
The similarities are driven by another fundamental: although the outcome may be uncertain at
the beginning of a product development job, the process should be repeatable.
Now, let’s consider the Womack and Jones’ 5 steps to lean3:
1) Precisely specify value by specific product;
2) Identify the value stream for each product;
3) Make value flow without interruptions;
4) Let the customer pull value from the producer;
5) Pursue perfection.
3 Womack J.P., Jones D.T., Lean Thinking: Banish Waste and Create Wealth in Your Corporation, Simon & Schuster, New York, 1996.
13
In case of development processes, it is necessary to somehow re-imagine how the concepts of
value, value stream, flow and pull apply, as shown in Table 1:
Manufacturing Product development
Value Visible at each step, defined
goal
Harder to see, emergent
goal
Value Stream Parts and material Information and knowledge
Flow Iterations are waste Planned iterations must be
efficient
Pull Driven by takt time Driven by needs of the
enterprise
Perfection Process repeatable without
errors
Process enables enterprise
improvement
Table 1 Applying the five lean steps to Product Development processes
Value, especially as the process is underway, is harder to see, and the definition of value
added is more complex: the value stream consists of information and knowledge, not the easy
to track material flows in the factory. The “pull” to which the system should respond is also
rarely a simple customer demand that can be used to calculate a takt time; product
development operations are usually intermediate steps in an overall enterprise effort to
create value. Finally, perfection is even harder to reach, as simply doing the process very fast
and perfectly with minimal resource used is not the final goal; efficient product development
process is simply and enabler of better enterprise performance and better products.
Another important consideration is the following: product development and factory (=
manufacturing) value stream mapping have an additional common point: in both cases,
making lean the local process by mean of value stream mapping is necessary, but not sufficient
to achieving a lean enterprise. In the factory efficiency in producing a product that customer
wants is clearly desirable. However, lean practices only in the factory produce only marginal
gains, that means, they are not sufficient. It is clear that product development has a great deal
of leverage on both the creation of the right product, and the enabling of lean production
through appropriate design. It can be tempting to consider product development process
14
efficiency as a secondary problem: this would be a mistake. Trying to leverage a process that
is not time-efficient to enable either lean enterprise transformation or the rapid evolution of
better products is not going to work: lean product development processes are necessary.
1.2 The followed methodology
After having introduced the concept of PDVSM and the application boundaries, we will
assume here that a process has been selected for improvement. Now it is time to identify the
stakeholders, formally define the scope of the process and the value created by that process.
1.2.1 Identifying key stakeholders
Stakeholders are the people who derive value of any sort from a process; without identifying
them, their expectations for the process, its outputs, and the improvement of both, it is not
possible to define value in a useful way.
In traditional factory Value Stream Mapping, the only explicit stakeholder of importance is the
buyer of the product of the factory (the “customer”), and his or her expectations are assumed
to be simple: a certain number of units in a given amount of time, on time, and to some
standard of quality. Other stakeholders are implicitly assumed to benefit from the elimination
of waste and pursuit of perfection, while implicit demands are placed on a third set (suppliers,
workers) to conform to the improved process4. In product development process, it is the need
of the enterprise that determine pace (e.g., a large-scale development program may need a
certain process to be completed in a given time to stay on schedule), while the downstream
processes (or internal customers) define the necessary quality.
Considering what said above, in the optic of performing PDVSM analysis, will be explicitly
included also the expectations of process workers, as well as the upstream/downstream
processes. Identify the key stakeholders and, as quantitatively as possible, their expectations
for both the process and its improvements is the key input into the specification of the value,
discussed in the next sections.
4 Enterprise Value Stream Mapping and Analysis, Lean Aerospace Initiative, MIT, 2003.
15
1.2.2 Framing the problem
Rother and Shook5 define a manufacturing value stream bounded by the receiving and
shipping “doors” of a single facility (a “door-to-door” value stream). Also in the case of a
product development process, the limits under consideration must be equally clearly defined.
The process bounds include the beginning and the ending point of the process, and its
organizational boundaries. The product (or products) on which the process operates should
be specified. The owner will provide the point for direct responsibility for the stream, and it
can be either an individual or a group. The output provides reason for the stream to exist; the
customers then receive the product from the owner at the end of the value stream; these
customers do not necessarily represent someone external to the organization, they may
include internal customers. The initial inputs as well as the additional knowledge and
information are the raw materials on which the process operates. The constraints place limits
of many sort on the process.
Figure 3 illustrates the bounds that have to be defined in order to apply the Value Stream
Mapping to the process:
Figure 3 Bounding the problem to which PDVSM will be applied
5 Rother M., Shook J., Learning to see: Value Stream Mapping to add value and eliminate MUDA, Spi edition
16
1.2.3 Defining the Value
Defining the value of a product development process is probably the most critical aspect of
the whole procedure; that’s because without a working definition of the value created by the
mapped process, and an appreciation of how much value is created, it is not possible to guide
any improvement effort.
The underlying assumption is, of course, that the overall project under analysis is, in fact,
value added. The aim is to do it efficiently and well, so that the larger enterprise can get on
with the task of providing value to all the stakeholders. To do this, value must be understood
in two rather different contexts: the value of the process output to the larger enterprise, and
the creation of value during the carrying out of the individual tasks that make up the process.
Figure 4 illustrates these value concepts:
Figure 4 Process value questions
The goal is to do the process well, efficiently and on time.
A general statement that can be adopted to clearly state the goal of the improvement process
is:
Produce the required outputs, without defects, as efficiently as possible, and at the right time.
After the goal has been defined, there is the need of a basis for evaluation of how activities
within the process contribute to that goal. The question is expressed graphically in Figure 5 ,
which shows the process under consideration decomposed into a series of individual tasks:
17
Figure 5 Value creation
Rather than rating activities simply as value-added or non-value added, Chase6 proposed a list
of general aspects of value that a task could contribute. It is reported since it may be very
useful when applying the PDVSM procedure to a given process (as it will be done later on for
the Purchasing process, object of this study). This is entirely presented in Table 2, as the
particular process may require consideration of some or all the aspects of value presented
here, or even definitions of new ones under the “other” category.
1.2.4 Process breakdown and data collection
The first step is to identify the tasks that make up the process, and the basic flows of
information between them. A decision to be made early is how detailed the process break
down will be. Excessively high-level breakdowns (not enough identified tasks) will not
provide much insight into the process; excessively detailed ones will become intractable: the
choice made for this study is to stay between 10 and 20 activities, because the objective is not
to build a complex simulation or a model for long-term study, but rather to perform a “quick”
analysis aimed at suggesting possible improvements, and quantitatively estimate the effects.
6 Chase, James P., Value creation in the product development process, Massachusetts Institute of Technology, 2001.
18
Table 2 Aspects of value in Product Development tasks
Symbols that we adopted for studying the process are listed in Table 3.
After having mapped the AS-IS configuration of the process under analysis, it is time to collect
data both on timings and possible waste sources, together with a quantitative assessment of
value, that has been unambiguously defined in the previous step.
Task contributes to:
Definition of End Product with desired Functional Performance
The task affects the definition and/or functionality of the end product delivered to the customer. It contributes
directly to either the function or the form that affects the function.
For example, requirements specification, design decisions, material/part/subsystem specification, geometry
specification, etc.
Definition of Processes do deliver product
The task directly affects the processes necessary to deliver the end product to the customer. It includes the
design or procurement of the tools and processes necessary for manufacturing, testing, certification and/or
other downstream processes, such as the creation of manufacturing and assembly procedures.
Reduction of risks and uncertainties
The task contributes to eliminating uncertainties in performance, cost, and/or schedule. Typically, tasks
include the analysis, prototyping, and testing of the product; the testing of tools/production processes, risk
analysis, and cost/schedule management.
Forming final output
The task directly contributes to the final documentation given to the customer or manufacturer. This typically
includes the documentation of the materials, parts, subsystems, and systems, and documentation to meet legal
and contractual constraints.
Facilitating communication
The task aids necessary communication. Typically includes reviews, meetings, and discussions with other
company or industry personnel.
Enabling other tasks
The task is necessary for other tasks to proceed, although it does not directly contribute to the design,
production, or testing of the product.
Meeting or reducing Cost and/or schedule
The task emphasizes maintaining or improving cost and/or schedule, e.g., many management and process
improvement tasks.
Learning or resource improvement
The task contributes to the skill base necessary to do future work. This definition includes developing greater
knowledge, improving tools or processes, creating new technologies, and communicating this knowledge
throughout the team.
Enhancing employee job satisfaction
The task is a positive experience that increases the desire of the employee to do similar tasks; it enhances the
professional development or skill base of the employee.
Other
The task performs a necessary or valuable function not covered in the above categories. Examples may
include contributions to work environment, environmental impact reduction, satisfying of regulatory or
contractual requirements, the following of mandated processes, or the satisfaction other constraints.
19
Collecting and using data requires a balance between the effort involved and the payoff
expected. The point is to achieve a lean process, not to build a complete and precise model of
the process.
Table 3 Process mapping symbols
In order to structure our data collection, we will rely on some basic advices7:
Concentrate on what you need: collect the data which are related to the problem
under study;
7 Oppenheim, Bodan W., Lean Product Development flow, System Engineering, Vol. 7, October 2004.
Symbol Function
Activity
Represents an activity in
which the process is
broken down, and the
resource that is involved.
External factor
Represents activity or
information sources
external to the process
under study.Decision task
Represents a decision
point, and can have two or
more major oucomes,
based on the answer to
the question.
Information flow
Information on the main
flow of the value stream
or reworks.
Information inventory
Information flow is stuck
because of wasteful wait
times.
Burst
Draws attention to special
feature or problem.
Resource
Activity name
<noun>
Question?
I
20
Exploit what you can find: often the data needed is not the primary purpose of the
existing documents;
Make do with what you have: often data is imperfect; time and error rates are likely to
be estimates. The data will be affected by the act of observing and by the bias of the
data takers. All of this is normal, and most of it does not matter: if the data leads to the
critical problem, is adequate;
Be honest: identify the sources and likely reliability of data. Note the level of
estimation, possible biases and any other problem with the data.
Dig deep only when you must: the only time to do further work to get either greater
accuracy or a finer breakdown of the data is when critical problems are analyzed,
looking for solutions. If the analysis hinges on a small set of data (as it will be in our
case), it is important to make sure that this data is accurate.
In order to collect data, it is necessary to define, a first, some metrics, that vary according to
the kind on problem under analysis.
In our case, we will adopt:
Elapsed Time (ET): clock or calendar time it takes to when the activity is enabled to
start, to when it is completed;
In-process Time (IPT): hours of continuous work it takes to do the activity. We will
also define the Rework In-process Time;
Core Process Time (CPT): hours (or other time units) of continuous work spent on core
task excluding setup, trouble shooting, information gathering, etc. This is usually called
Value Added Time (VAT);
Waiting Time (WT): time an activity has to wait before starting. We will also define the
Rework Waiting Time.
Rework rate: percentage chance an activity needs to be performed in an iterative or
rework prone process.
1.2.5 Waste and improvements identification
Now that a general view of the process has been defined, it is time to set about improving it.
The first and most important step is the elimination of waste from the process in all of its
21
forms. The sources of waste in product development processes are many and varied; in this
section we will review the traditional lean seven wastes (waiting, inventory, over-processing,
over-production, transportation, unnecessary movement and defective products), re-
interpreting them inside the product development process framework.
Table 4 show how lean wastes have been “translated” into information wastes, providing
some examples and investigating some of the possible causes.
Once collected and understood the various sources of waste, it is possible, together with all
the other data collected, to explore different ways to make improvements to the process.
Below the main criteria we will adopt to improve the process under study:
Clear external constraints: to the extent possible, clear external causes of waiting;
Eliminate unnecessary or inefficient reviews and approvals: here the issue is what
value is created. Reviews can be used to reduce risk, and in this optic may be Value
Added. On the other hand, if they are used for catching mistakes, they are at best
necessary but NVA activities;
Break down monuments: Womack defines a “monument” as any machine or process
which is too large to be moved to accommodate dynamic reconfigurations as the value
stream changes. In “Lean Enterprise Value”, Murman et al. expand the definition to
include assets, processes or mindsets that were originally created for a good reason,
but which have not adapted to changing circumstances. From the book: “the very
institutions, infrastructure and mindsets that enable success under one set of
circumstances can become barriers under a new set of circumstances”. Many activities
that appear NVA once had an important motivation, but have become impediments
under current conditions.
Monuments should be eliminated; however it is important to understand where they
came from. In Product Development processes, the original motivation is often the
mitigation of specific risks, and in any case it is important to make sure that the
original Value added intent of eliminated monument is not lost.
Eliminate unnecessary documents and (Re-) formatting. Sometimes it is found that
information is created that has no user: this is pure waste and should be eliminated.
Much more often, the information appears to flow from the task creating it to the task
using it, but on closer examination it does it very inefficiently. Rarely , formatting work
22
will actually be value added: the effort saved downstream by, for example, recasting
results into a form that is directly usable to a downstream tool, or presenting a
decision-maker with a clear choice supported by logically presented reductions of data,
may not justify non-trivial effort.
The aim in all cases must be to eliminate all non-value adding documents, formatting
and data handling. If simpler channels (emails, websites and on-line portals) can
effectively transmit information, they should be consistently used. Id documents are
actually needed, they should be template and standardized, such that the necessary
information can be dropped in with minimum effort.
With all what discussed until now, it is possible to implements PDVSM to the mapped process,
and identify one (or more alternative) improved configurations. With the data collected,
quantitative estimations based on the metrics defined can be (and have to be) performed, in
order to allow comparisons based on several, different aspects (time related, value related,
waste related and so on).
The application of the proposed methodology to a real case will be the object of next chapter.
23
Table 4 Information wastes
Type of information waste Examples Causes
People waiting for information
- Lack of access
- Untimely update of data bases
- Multiple approvals
- Poorly designed or executed
process to provide information
Information waiting for people- Information created too soon may be
obsolete by the time it is used
Too much information - Poor understanding of user needs
Mutiple/redundant sources- Tendency for everybody to maintain
their own files
Outdated/obsolete information
- Lack of disciplined systems for
updating new and purging old
information
- Inadequate archiving standards or
practices
"Just in case" information
- Collection, processing and sorage of
every element of data that process
participants can think of, wether or not a
specific end use has been identified
Excessive/custom formatting - Lack of standardization
Numerous, fragmented reports
- Poor outut design
- Lack of understanding of the needs of
the users of process outputs
Excessive approvals for information
release
- Stove pipe, command and control
mentality
Unncessary detail and accuracy - More detail than necessary
Pushing, not pulling data, information - Uncontrolled processes
Over-dissemination
- Poor understanding of each
participant's needs
- Send all information to everyone,
rather than to meet specific needs
Information handled by multiple
people before arriving at user
- Lack of direct access due to IT system
limits, organizational inefficiencies,
security issues
Information hunting
- Lack of clear information flow paths,
failure of process to produce
information needed
Data re-formatting or reentry
- Incompatible information types
- Incompatible software systems or tools
- Lack of availability, knowledge or
training in conversation and liniking
systems
Walking to information, retrieving
printed materials
- Lack of distributed, direct access
- Lack of digital versions of heritage
information
Excessive keyboard, mouse operations
- Lack of training
- Poorly designed user interfaces
- Incompatible software suites
- Too much information to sort through
Poor physical arrangement of
organization
- Team member not co-located
- Organization structure inhibits
formation of right teams
Errors in data reporting/entries- Human error
- Poorly designed input templates
Errors in information provided to
customers
- Lack of disciplined reviews, tests,
verfication
Information does not make sense to
user
- Raw data delivered when user needs
derived information, recommendations
or decisions
Defects
Erroneous data, information,
reports
Waiting
Idle time due to information
Inventory
Information that is unused or is
"work in progress"
Excessive Processing
Information processing beyond
requirements
Over production
Producing, distributing more
information than needed
Transportation
Unnecessary movement of
information between people,
organizations or systems
Unnecessary motion
Unnecessary human movement
(physical or user movement between
tools or system)
24
CHAPTER 2
2.1 Problem definition
2.1.1 Process identification
In Chapter Y we have given a general overview of the major issues and trends that affect,
today, almost all the companies whose business is focused on the development of new
products/services with an high engineering content, and that are mostly linked with the
organization of all the activities by projects.
The objective of this study is to apply the Product Development Value Stream Mapping inside
a company assembling mechanical components for vehicle clutches (the so-called Dual Mass
Flywheel, linking the clutch mechanism to the engine). The company has a well-structured
stage-and-gate Product Development Process, which is shown in Figure 6.
Figure 6 Scheme of the Product Development Process
25
Every time a customer (among the world major automakers) sends a Request for quotation,
the company decides whether it is worth to try to win the award or not. In case the company
decides to answer the RFQ, a new development project is started.
The whole product development process is divided into 14 Milestones, among which the most
important one is customer’s Start Of Production (SOP) date: based on this time, all the other
milestones and due dates are scheduled backwards; in addition, every milestone is assigned to
one out of five possible functions, that is appointed as formal “owner” (Sales, Project
Management, Purchasing, Quality or R&D).
It is clear to understand that, as a result of planning essentially based on one single reference
date (the SOP date given by the customer), each sub-process inside the product development
value stream shown in Figure 6 is critical, since any delay may affect, even seriously, the
whole project schedule: this means that, for every gate-to-gate process (i.e. the process in
between two sequential milestones) it is possible to identify, based on past-projects planning,
a maximum time in which every process must be concluded, beyond which any delay
inexorably impacts of the overall Product Development schedule.
Throughout this chapter, we will follow step by step the approach defined in Chapter 1, in
order to show how the defined Product Development Value Stream Mapping methodology can
be applied in order to improve one of the several processes that are part of a Product
development project.
The process that will be object of this study has already been highlighted (red circles) in
Figure 6: it is the Sourcing process, by which the suppliers of “buy” components are selected,
the design is developed until final validation (the so called “Design freeze” milestone). Two
are the main project actors involved: Project Buyer and R&D member.
One important remark: actually, it is not totally appropriate to refer exclusively to “Sourcing”,
since what is going to be analyzed within this study is rather the process that results from the
parallel development of what in Figure 6 is circled in red: “RFQ Suppliers + Suppliers award”
in charge of Project Buyer and the “Prototyping and design validation” process, attributed to
R&D. Indeed, the two processes cannot be treated separately, also because one of the
objectives is to reduce the likelihood that a project miss the Design Freeze milestone, whose
owner is, indeed, R&D.
26
Anyways, for the sake of simplicity, through the rest of this work we will only refer to this
“combination” of two different processes, which interplay, as Sourcing process.
The reason why this process has been selected comes from what emerges from company’s
internal data:
55% of projects (currently on-hand and closed ones) have been assigned a “red” status
at least once during their life, that means, customer SOP date cannot be respected if ad-
hoc back-up solutions are not put in place;
Among all the previous projects, 63% of them did not meet Design Freeze milestone
due date, that means, the customer could not “freeze” the design of the assembled
finished part because of a delay in validating the design of one or more components
(design validation is made through bench tests, which are a critical phase in terms of
timing, as it will be discussed later);
The project Buyer is a scarce resource, since he is working on more projects in parallel,
at different phases of their life: thus, it can happen that he is performing the sourcing
process for components belonging to different projects, and at the same time he is also
performing activities out of the sourcing (i.e. following the tool launch, which is
another critical activity). All project buyers interviewed pointed out an excessive
workload that do not allow to perform on time all the activities they have in charge.
According to scheduled timings, the maximum time in which all component suppliers have
to be selected should be, on average, 7 months, in order to allow Design Freeze of the final
product after maximum 8 months after project Kick Off (the meeting, after customer
award, in which all the actors are aligned, and the project can officially start being
executed). Furthermore, as we will see later, there are some components provided by
designers suppliers: in this case, the company only provides the functional and technical
requirements to the supplier, that then usually gives different alternative proposals. Those
suppliers have to be nominated well in advance with respect to the others, because after
the nomination, all the development process takes place, and after that, several bench
tests have to be performed (a complete test cycle for critical components lasts approx. 1.5
months and, in case something go wrong during the execution, it has to be totally
repeated). That’s why the Sourcing process for those components should be completed in
27
no more than 8 - 4.5 = 3.5 months. The company names the procedure by which it selects
and nominates the supplier “Sourcing Committee” (SoCo), as it will be described later.
Figure 7 gives an overall view on maximum timing issues mentioned above.
Kick offSoCo
(for Criticalparts)
SoCoDesignFreeze
7 MONTHS
3.5 MONTHS
8 MONTHS
Figure 7 Maximum timings between Sourcing process Milestones
Considering all what discussed until now, it emerges the necessity to apply the Product
Development Value Stream Mapping defined before (that, from now on, for the sake of
simplicity will be referred as VSM). The objective is twofold: on one side, we want to reduce
the total time necessary to complete the Sourcing process (keeping it lower than 7 months),
by taking care, on the other side, to reduce as much as possible Project Buyer’s workload, in
order to allow a better allocation of working time between sourcing and non-sourcing
activities.
2.1.2 Component definition
In order to better understand all what is going to be discussed, it is necessary to understand
the features of purchased components, i.e. the parts that will be assembled by the company in
order to create the final assembled Dual Mass Flywheel (DMF), as illustrated in Figure 8.
As reasonably expectable, different components will have different timings and paths inside
the processes under study; thus, an analysis has been made in order to classify the buy
components into four categories.
28
Figure 8 Main components constituting the DMF
A criticity level within the range 1,…,4 (with 1 = standard component and 4 = critical
component) has been attributed based on the experience of Senior R&D team members and
Buyers:
The "Buy Criticity" score takes into consideration the complexity of negotiation,
meaning the complexity of ensuring a final price below targets (i.e. good profitability
indicators), and the relative bargaining power of the company towards supplier.
The higher the cost % contribution of the component, the higher the impact of savings
on overall profitability of the final product.
The "R&D criticity" score takes into consideration the level of technical complexity
and amount of modifications and design changes required to ensure design freeze. It
also takes into account the company’s level of know-how on the specific component,
allowing for an higher level of confidence in discussing the design and technical
characteristics. The lower the know-how, the higher the criticity.
Designer suppliers components have, by definition, criticity level = 4 on both criteria.
Table 5 shows the details of those evaluations:
29
Table 5 Evaluation of “buy” components
The overall criticity is attributed considering the sum of Buy and R&D criticity scores, and
assigning the overall criticity score according to:
4 if sum = 7 or 8
3 if sum = 5, 6 or 7
2 if sum = 3 or 4
1 if sum = 1 or 2.
Furthermore, for the purposes of this study, the following assumptions will hold:
An average project consists of 18 buy components to be sourced (whose overall cost
impact is around 93%), of which:
o 2 are made by Suppliers Designers (thus are, by definition critical), meaning
that the company outsources both the design and production, providing the
supplier functional requirements and evaluating the various design
alternatives proposed.
Component % cost Buy Criticity R&D Criticity Overall criticityPrimary cover 4,30% 3 2 3
Secondary flywheel (raw) 13% 3 2 3
Pin 0,01% 1 1 1
Curved Springs 13,30% 4 4 4
Ball bearing 5,50% 4 4 4
Hub 9% 2 2 2
Primary flywheel 9,40% 3 2 3
Ring gear 6,70% 3 2 3
Rivet 0,35% 1 1 1
Spacer 0,01% 1 1 1
Inertia ring 4% 2 1 2
Seal plastic washer 1,20% 1 1 1
Mass 7% 3 3 3
Slider 1,30% 1 1 1
Rolling spacer 7% 2 3 3
Roller 2,50% 2 2 2
Stopper 2,20% 2 2 2
Drive plate 6,50% 2 4 3
Make components 6,73% - - -
Inner pendulum
components
Designer
suppliers
"Buy" components
30
o The other components are made by Suppliers Manufacturers, which means that
the company provides technical specifications and drawings, and the supplier
evaluates the feasibility, proposing alternatives or improvements.
The other components are made internally, thus are out of the scope of this study. In
general, we have only 3 "make" components: Flexplate, Spring Guide and Seal washer.
According to the scores given, the 18 components have been split as follows:
2.2 Application of VSM methodology to the case study
2.2.1 Stakeholders identification and process bounding
The process under study goes from the Project Kick Off up to the Design Freeze,
corresponding to the validation of all the components design, after performing bench tests on
prototypes. The owner of this process is the Project Buyer, but also R&D is involved in the
various phases since it has to work in contact with the suppliers in order to define the design,
based on technical and functional specifications.
Figure 9 conceptually shows the inputs, outputs, knowledge-info necessary and constraints
for the process. In particular, the inputs aim at satisfying requirements coming from different
customers (with the word customer here we do not only refer to the external customer, but
also internal ones, which are also the stakeholders involved. In particular, the company itself
can be considered a direct stakeholder, whose main interest is the profitability of the
product/process under development: as a consequence of that, the various figures involved in
at different points of the process, such as Project Buyer, R&D and Segment Leaders have to be
included among the stakeholders.
Criticity level N. components1 5
2 4
3 7
4 2
31
This identification step is very important not only in order to define the problem boundaries,
but first of all in order to individuate where the necessary information that will be needed in
order to analyze the process can be obtained, as will be done in the following chapter.
Inputs
- Bill of Materials- Project data from
Project Kick off
Knowledge and info
- Technical/functional specifications from R&D- Support from Segment
Leader- Negotiation tacticts and
tools
Constraints
- Cost targets- Milestones timing
- Project Buyer workload
Kick offDesignFreeze
SOURCING PROCESS
Organization: Purchasing dept. + R&D
Owner: Project Buyer – R&D
Outputs
- Selected suppliers- Component design
validated
Final customer
The company (profitability)
Owners of following processes
SoCoSoCo
(for Criticalparts)
Figure 9 Bounding the process
2.2.2 Value definition
Table 2 summarizes some general aspects of value that can be applied to a variety of
processes. Of course, they should be adapted to the specific issues under analysis, in
particular, considering different factors such as stakeholders involved, objectives of the study,
and the nature of the process itself.
That’s why we end up with the definition of 6 value contributions, based on which the
activities that will be derived from process break down (see § 1.2.4) will be evaluated, and a
score will be attributed.
These value attributes are:
V1 – Definition of end component with desired functional performance: the
activity affects the definition and/or functionality of the end component. It contributes
directly to either the function or the form that affects the function.
32
V2 - Facilitate communication: the activity aids necessary communication, both
internally and with external stakeholders/contributors.
V3 - Enabling other activities: the activity is necessary for other activities to proceed,
although it does not directly contribute to design or targets compliance.
V4 - Reduce workload/schedule: the activity concurs in reducing process time and
resource overload.
V5 - Form of output: the activity directly contributes in forming a
document/information that is a deliverable of a specific customer milestone.
V6 - Profitability targets satisfaction: the activity concurs in meeting the profitability
targets set for the project.
Each activity resulting from process breakdown will be given a score on each of these value
attributes, in order to allow a better understanding of the overall contribution and, at the
same time, to identify possible points for improvements.
2.2.3 Process breakdown
Now that the process under analysis has been bounded, key stakeholders involved identified
and “value” has been defined accordingly, it is time to break down the sourcing process. As
anticipated in Chapter 1, the objective is to discompose the process in 10-20 activities, for
which it is easy to assess the resources involved and the amount of time/effort they spend.
In order to do this, at first we had a look at the Project manager’s planning files, but we
discovered that the sourcing process is treated as a unique block to which is attributed an
average planned duration of 7 months (accordingly to what discussed above): thus, it has
been necessary the help of the people involved. Spending some time interviewing the actors
involved, and putting together the material collected allowed to break down the process into
13 activities (or steps), each performed by one/two actors among the following:
Project Buyer (PB): he has to perform all the activities related to supplier selection and
the accomplishment of economic targets satisfaction (through negotiation);
Segment Leaders (SL): each of them manages a commodity (e.g. Plastics, Steel &
transformations, Electronics) at Business Group level (in this case, Powertrain
Systems). He is responsible to approve the suppliers nomination for each component
that falls within its commodity if competence;
33
R&D expert: he has to manage all the activities related to technical/functional
specifications, design definition and validation.
In addition, some activities require the support (“S”) of other actors, such as the Project
Manager (PM) and the Supplier Quality Assurance responsible (SQA), that is, the person
responsible to manage the relationship with each specific customer in order to guarantee the
quality standards are always satisfied.
Table 6 shows the activities that have been identified (the order is non-sequential), with a
short description of each of them, the individuation of the actor(s) performing it (“R”) and the
eventual support figure(s) (“S”), whose involvement is so marginal that will not be considered
in the analysis that will follow.
The AS-IS Sourcing process is mapped in Figure 1010, according to the symbols defined in §
1.2.4.
Figure 10 AS-IS Sourcing process scheme
One clarifications on the notation used: the dotted lines indicate the path that is followed by
components provided by Designer Suppliers.
34
Table 6 AS-IS Sourcing Process breakdown
Activity Description of the activity R S Inputs Outputs
Project scope, timing, project
organization, resources, product
definition, process definition,
sourcing plan, financial status.
BOM updloaded on
Puma
The new project is created on Puma (volumes,
extraction of buy components, put initial targets
with time evolution for productivity, tooling cost
forecasted).
BOM insertion in Puma format
PB CAA All buy components initialized on
Purchasing portal (Puma)
1Info collection & supplier pre-
selection
Target setting, cost model, sourcing strategy,
negotiation tacticts, timing;
Pre-selects suppliers to be RFQed based on VPSP
status for the Categories/ Technologies as updated
by the GSD/SL in PuMa, anticipates bundling
opportunities (if volumes are high)
PBSL, SQA,
PM
Puma BOM, VPSP status set
by SLBid list
2 Pre-Soco preparation
Generation of a standard 13 pages ppt
presentation.
When ready, Pre-Soco slot booking
PB Step 1Standard Pre-Soco ppt
presentation
3 Pre-Soco
-Validation of Bid List or remove pre-selected
suppliers or includes additional “Eligible”
suppliers.
-Validation of cost model information to Project
Buyer and validates target settings.
-Suggestion or challenge of possible Bundling
Opportunities.
- Worldwide strategy definition for the specific
component
SL
PB Step 2
4aTechnical specifications +
drawings to supplier
R&D provides drawings with technical
specifications (materials, critical parameters,
materials, treatments…)
R&DDrawing and updated technical
specifications sent to suppliers
4bFunctional specifications to
supplier
R&D provides the functional specifications to
supplier, necessary in order to make design
proposals
R&DTechnical requirements sent to
suppliers
5 VRF preparation
PB is in charge of completing his part and, after
Logistics, Quality and R&D have completed theirs,
to send it to the supplier
PB
Logistics
Quality,
R&D
VRF sent to suppliers
6 RFQSend invitation letter, volumes, VRF, drawings,
SOP date and other project milestones.PB VRF, project data on Puma
7a Offers collection
PB collects the offers coming from the various
suppliers with cost breakdowns and other info and
puts all them together in order to compare
PBVRF signed by supplier +
complete economic offer
File with the comparison of the
various offers received
7b Technical offers collection
Collection of technical offers coming from the
various suppliers, whith different preliminar
design proposals
R&DVRF signed by supplier +
technical proposal(s)
7c Commercial offers collection
PB collects the offers coming from the various
suppliers, after the preliminary design has been
validated, with cost breakdowns and other info
and puts all them together in order to compare
PB
All the economic offers from
suppliers based on the
preliminary design approved
with the technical DR (Step
9b)
File with the comparison of the
various offers received
8a Design review
Discuss about technical issues, modifications,
improvement suggestions between supplier and
Valeo's R&D, until having supplier full aware of
every detail of preliminary design that is validated.
This acitivy can be reiterated until reaching a full
undertanding between manufacturer and Valeo's
R&D.
R&D SQA , PB Step 4a
8b Technical design review
R&D reviews the various preliminar design
proposed, discusses with the supplier, and if the
preliminary design is not validated then another
technical offers is submitted by suppliers, until
design is validated (=accepted).
R&D Step 4b
9 NegotiationNegotiation of prices, productivity, discounts,
business linkPB SL
Offers, project targets, Group
rules
10 SoCo preparation
Creation of a standard presentation showing
offers, signed drawings, VRF signed
Panel compliance Criteria, Supplier RFQ analysis
PB Standard Soco ppt presentation
11 SoCo
Meeting with the SL, during which all the Soco
information are reviewed.
If all is OK, then the SoCo must be validated by SL.
SL
PBOther
PTMsPre-Soco, VRF, negotiation
12 Pre SoCo validated The SL validates the Pre Soco SL Step 3Validated bid list and sourcing
strategy
13 SoCo validated The SL validates the Soco SL Step 11Validated bid list and sourcing
strategy
Prototyping and bench tests
The supplier designs and/or build prototypes for
testing.
The work continues until the component design is
compliant with all tests.
Test
teamSQA Step 8a/8b
Design freeze = Component with
all it features fully compliant with
customer requirements.
All components have successfully
passed all bench testsDESIGN FREEZE
KICK OFF
35
2.2.4 Data collection
In order to apply the VSM methodology defined to the Sourcing process and quantitatively
estimate and evaluate the efficacy of the improvements that will be proposed, it is necessary
to collect information on:
Timings associated to the process: In-Process Time, Core process Time, Waiting Time
(as defined in § 1.2.4) ;
Chance of rework (%) and associated Rework process time and Waiting Times;
Evaluation of the input(s) quality according to four major criteria: quality, utility,
formatting and transfer;
Output identification and transfer method;
Value evaluation (based on the six criteria previously defined);
Identification of waste sources (based on the seven info wasted defined before).
In order to collect these information, we decided to create a questionnaire to be filled by the
actors directly involved in the process, that are, 3 project buyers (one Senior with 5-year
experience inside the company, and two Junior, with less than two years), 2 R&D experts, 2
suppliers (that have a long relationship with the company), and one of the various Segment
Leaders involved, which can provide an higher-level point of view especially on the activities
most critical in terms of economic targets satisfaction (thus, giving a reliable score on value
V6 that takes into account how the Purchasing process structure is designed in order to
comply with overall company’s profitability, and considering these issues if and when change
will be proposed on crucial activities like SoCo).
The questionnaire that has been elaborated is shown in Figure 1111, while criteria defined for
the attribution of a score to Inputs and Value parameters are detailed in Figure 122.
Timing definitions have already been given in §1.2.4: what is important to point out now is
that the main focus will be on those activities for which discrepancies between In-process
time and Core process time emerge: this would essentially mean that there is a share of time
spent on those activities which is not perceived as Value Added, and then further
investigations will be made, based on the results that will emerge from the other sections of
the questionnaire, in order to individuate the root cause of those NVA. Anyways, in general
36
great attention will be put on those activities for which any kind of waste of NVA content
emerges .
Figure 11 Data collection questionnaire
%
Name Name
Source Source
Tansfer Tansfer
Quality Quality
Utility Utility
Format Format
Name Name
Receiver Receiver
Transfer by Transfer by
Inventory
Excessive processing
Over Production
Transportation
Unnecessary motion
Defects
Waiting
Transfer by
Value
Non - Value - Added Enabling Value Added
1 - - - - - 2 - - - - - 3 - - - - - 4 - - - - - 5
V1 - Functional performance 1 2 3 4 5 N/A V4 - Reduce workload/schedule 1 2 3 4 5 N/A
V2 - Facilitate communication 1 2 3 4 5 N/A V5 - Form of output 1 2 3 4 5 N/A
V3 - Enabling other activities 1 2 3 4 5 N/A V6 - Profitabilty targets satisfaction 1 2 3 4 5 N/A
INFORMATION WASTE SOURCES
Name
Receiver
1 2 3 4 5 N/A 1 2 3 4 5 N/A Format 1 2 3 4 5 N/A
Output #1 Output #2 Output #3
1 2 3 4 5 N/A 1 2 3 4 5 N/A Quality 1 2 3 4 5 N/A
1 2 3 4 5 N/A 1 2 3 4 5 N/A Utility 1 2 3 4 5 N/A
Source
Tansfer
Input #1 Input #2 Input #3
Name
Seniority Chance of rework / Time (h)
Type of component Rework wait time (h)
Data collection sheet
GENERAL RESOURCES
Activity name
Person performing
In- process time (h)
Role
Core ProcessTime (h)
Wait time (h)
37
Figure 12 Data collection sheet legend
Quality
5 - Significantly more information than needed
4 - More information than needed
3 - Quality is just right
2- Information is missing
1- Information is inaccurate and/or untrustworthy
Formatting
5 - Ideal formatting for immediate use
4 - Fairly good formatting
3 - Acceptabe formatting
2 - Some reformatting necessary
1 - Reformatting necessary
Utility
5 - Direct and critical contribution
4 - Important contribution
3 - Beneficial contribution
2 - Indirect contribution
1 - No contribution
Transfer: the method of transfer by which the
input arrives to the activity
V1 - Functional performance (FP)
Functional performance of the end component to
be assembled and delivered to the customer
5 - Direct specification of major FP parameters
4 - Direct specification of FP parameters
3 - Direct specification of minor FP parameters
2 - Indirect specification of FP parameters
1 - Possible specification of FP parameters
V2 - Facilitate communication
The activity aids necessary communication:
5 - In an effective way
4 - Not always, but efffectively
3 - Often, but non very effective
2 - Almost never
1 - Does not facil itate at all necessary communication
V3 - Enabling other activities
Enabling other activities to occur
5 - Major checkpoint preventing further work
4 - Moderate checkpoint in process
3 - Task necessary for continued work
2 - Necessary, but not especially time-sensitive
1 - Necessary, but not time-sensitive
V4 - Reduce workload/schedule
Workload/schedule savings resulting from activity
execution
5 - In a systematic way
4 - Often occur but not systematically
3 - May occurr as a direct result of the act.
2 - Sometimes occurs but cannot be easily
reckognized as a direct consequence of the act.
1 - If occurs, it is not a consequence of the activity
V5 - Form of output
The form of the output of this activity
5 - Flows easily into a milestone deliverable
4 - Flows into a milestone deliverable with some
changes
3 - Flows easily into downstream activities
2 - Flows into next activities with some changes
1- Flows into next activity with major changes
V6 - Profitabilty targets satisfaction
The activity results in achieving target satisfaction
5 - In a systematic way
4 - Often occur but not systematically
3 - May occurr as a direct result of the act.
2 - Sometimes occurs but cannot be easily
reckognized as a direct consequence of the act.
1 - If occurs, it is not a consequence of the activity
Input criteria
Value Criteria
38
2.2.5 Summary of results
After collecting all the data from questionnaires, it is necessary to highlight the main points
emerged, on which the following proposed improvements identifications will be based.
Evaluation results are shown according to the questionnaire structure, thus divided in: Inputs,
Value and Information waste sources.
Inputs
Quality
o Low score (2) given by R&D for activity 7b – Technical offers collection, since it
happens often that some information is missing. This is confirmed by Designer
suppliers, that evaluate very bad the format with which R&D sends the
functional specifications (long email chains with high risk of missing critical
information).
o All the other activities show an overall high quality of the inputs, meaning that
they contain enough information.
Utility
o All inputs are evaluated as necessary for the successful completion of the
activity: this suggests that those info should not be eliminated by improvement
changes, but rather some evaluations can be made on their format (see below).
Format
o Low score (1) attributed by Designer suppliers to 7b – Technical offers
collection, as already pointed out.
o Low (1) by Project Buyer to 1 – Info collection, since reformatting is necessary.
o Low (1) by Project Buyer to 7a – Offer collection and 7c – Commercial offer
collection, since the Project Buyer indicates the necessity to re-formatting the
offers that come from suppliers.
o Low (1) by Project Buyer to 2 – Pre-SoCo preparation and 10 – SoCo preparation.
Value
V1 – Functional performance
39
o All the activities in charge by R&D got a score equal to 4 or 5: this means that
they are extremely important in terms of the functional performance of the end
components (and, as a consequence, also of the final product performance).
o The fact that 7b – Technical offers collection got a score equal to 5 on V1, but at
the same time it has got only 1 on Input quality clearly indicates that some
improvements are required.
o Also activity 11 – SoCo got a 5 by Segment Leader, on components with criticity
3 and 4. That’s because a good supplier(s) choice has a remarkable impact on
component performance, especially on those components provided by Designer
suppliers, who detains know-how and technology.
V2 – Facilitate communication
o All the activities do not show the drawback of preventing communication,
either internally or externally, since a constant interaction among the actors
involved is required.
V3 – Enabling other activities
o The major checkpoints identified are: 3 – Pre-SoCo, 11 – SoCo, 8a – Design
Review and 8b – Technical Design Review. These are the activities that, as shown
in Figure 1010, are followed by a validation. This implies that special attention
must be paid in order to find possible improvements capable to reduce the
chance of rework and/or the amount of components that need to be
“reworked”.
V4 – Reduce workload/schedule
o No activity has been identified as valuable in this sense (almost all of them got a
score equal to 3). This indicates that the process may beneficiate from the
introduction of improvements that allow to reduce resource workload, or
activity duration.
o Low score (1) by Project Buyers to 2 – Pre-SoCo preparation + 12 – Pre-SoCo
validation and 10 – SoCo preparation + 13 – SoCo validation.
V5 – Form of output
o Score = 5 by Project Buyers and Segment Leader to 11 – SoCo, since it
corresponds to a Project Milestone.
o Score = 4 by R&D to 8a – Design Review, since some changes usually are made
before Design Freeze milestone.
40
o Score = 2 by R&D to 4b – Functional specifications: this is in line with the low
score given by the supplier to the format with which R&D communicates
functional specifications, and also with the low score given by R&D to the input
of 7b – Technical offers collection.
o All the other activities received a score = 3, meaning that their outputs “flow
easily into downstream activities”.
V6 – Profitability targets satisfaction
o All the activities get a score = 3, except for 2 – Pre-SoCo (score = 4) and 11 –
SoCo (score = 5). This is rather obvious considering the nature of those
activities, that is, to select the best supplier on the basis of how their offers
comply with cost targets.
Information waste sources
Waiting
o After Pre-SoCo/SoCo presentation preparation, from 7 to 11 days of waiting
time before a slot is available Pre-SoCo/SoCo meeting.
o After Pre-Soco/SoCo meeting, it takes up to 3 days to be officially validated by
Segment Leader (validations is made on the Purchasing portal called PuMa).
Excessive processing
o Functional specifications communicated to Designer Suppliers originate long
email chains with too much information to sort through, with the risk that it is
not always completely updated, or something is missing.
Transportation
o For Pre-SoCo preparation, all necessary data must be taken from both Project
management portal and Purchasing portal, organized and re-formatted in order
to create the .ppt presentation.
o Economic offers collected from suppliers have to be re-formatted (with lack of
standard template) by each Project Buyer in order to analyze and compare
them.
Defects
o Errors/lack of necessary information in functional specifications are often
discovered too late, causing consistent delays on bench tests.
41
According to results collected from questionnaires, it has been possible to complete the
mapping of the AS-IS configuration highlighting the issues detected before, as shown in Figure
133. For the meaning of symbols adopted, see § 1.2.4.
Figure 13 Evaluated AS-IS Purchasing process value stream
2.3 Proposed improvements
On the basis of all the information collected through questionnaires and interviews, 2 macro-
areas for improvements have been identified:
1) Suppliers identification and selection (the so called Pre-SoCo and Soco procedures,
from preparation to validation) and economic offers management (from sending RFQ
to collecting offers from suppliers)
2) Specifications sharing with Designer Suppliers.
Thus, three improvement proposals are illustrated and discussed: their benefits are expected
to cover one or both of the previous areas, and their impacts will be quantitatively estimated
in § 3.3.
42
2.3.1 Pre-SoCo and Soco improvements
One of the most evident sources of waste identified with the Value Stream Mapping analysis is
related to the Pre Soco and Soco procedures.
In particular, for both processes it is possible to identify the following major sources of
time/effort waste:
The time spent in preparing a Power Point standard presentation, collecting
information coming from 3 different inputs: Kick Off presentation, VPSP status of all
the suppliers, and target information (from the BOM uploaded on Puma portal), which
has not additional value since it will not be used for any other purpose than the
meeting with the Segment Leader for validation.
The wait time necessary to book a slot for the meeting: in order to take into account
the time necessary to have both the Project Buyer and the Segment Leader available, it
is a consolidated internal procedure to book a 30 min slot from 7 to 11 days after
sending the complete presentation for approval.
The time the PB spends during the meeting, especially for low-criticity components,
can be considered as Non-value added, because it is very common that “the Segment
Leader only reviews the presentation, checking that it is compliant with the
indications provided well before in the Sourcing Plan”. In other words, the attendance
of the Project Buyer, for this kind of components, it is useless.
In some cases, after Pre-SoCo/SoCo meeting the Segment Leader ask for some changes:
this implies the re-iteration of all the previous steps, and related non-value
added/waiting times. This is rated as “valuable” in case of SoCo, mainly because of the
high impact on performance indicators and profitability. However, can be a major
source of delay in case of Pre-Soco, especially for non-critical components, when the
whole process is blocked only because of small modifications required.
The waiting time necessary for having the Pre-Soco/Soco officially approved after the
meeting: from the surveys made, this time has been approximated between 0 and 3
days after the meeting.
43
All the above mentioned waste sources, which can be classified as NVA or “Inventory”
according to the notation introduced with the Value Stream Mapping, as graphically shown in
Figure 13.
The following proposed improvements are evaluated, according to the issues detected before:
A) Introduction of “Light” Pre-SoCo and SoCo, according to the criticity level of the
component to be sourced and the rating of potential suppliers to be included in the bid
list.
B) Introduction of a single, (partially) automatically filled document, which we will call
“One Page”, that contains all the data on project, component to be sourced (volumes,
targets), Pre-Soco and Soco.
2.3.1.1 Light Pre-SoCo / SoCo
The idea behind this improvement proposal is to avoid the non-value added times for a
particular category of components, those for which the potential suppliers to be RFQed
satisfy the following conditions:
a) Supplier having a “Green” Panel Status (Listed, Preferred, Partner) – see below-
and confirmed OK in terms of Capacity and Turnover, or any supplier already
awarded for the specific component (same part number) in one or more other
development projects.
b) “Product Exists”, meaning that all the suppliers proposed for the bid list have
already supplied components very similar to the sourced one, with some minor
design modifications.
The supplier Panel Status (VPSP) is regularly updated by the Segment Leaders and/or the
Segment Directors, and consists in assigning the supplier to one out of four possible
categories:
44
Probation: Supplier which (i) either are newly introduced suppliers and still have
to demonstrate by facts that they can belong to one of the three other status levels.
Any newly introduced suppliers supplier will automatically fall into this status and
will stay in it for a minimum of 2 years from first SOP before possibly moving to one
of the other three status level; (ii) or previously holding one of three status levels
and are given a last chance of staying in the company panel of suppliers- such
supplier may not stay in this status for more than one year.
Listed: Supplier with which the company is working, which do not belong to one of
the other 4 VPSP status categories, whose relationship is viewed by the company
as serious and wanted for the middle/short term at least. Only considered if there is
neither Preferred nor Partner available for doing the business in the category.
Preferred: Suppliers different from Partner which show a real accompaniment of
the company by offering superior support, service and performance, whether
strategic for the company or not, whose relationship is cast for the long/middle
term (a supplier on which the company can really rely to sustain its growth and
development).
Partner: Suppliers that have a common strategic interest with the company, both
parties share it and have a declared will of working together for the long term as a
real partnership/ privileged relationship.
The Supplier Panel contains, at Group level, more than 3.000 suppliers, but data say that only
1.100 of them account for 95% of Total Purchasing Spend.
This proportions are valid also at the level considered for this study, since DMFs are made of
quite standard components, provided by a limited group of suppliers with a great know-how
and long-term relationship with the company. The following table highlights, for each
component, the percentage of listed, preferred or partner suppliers, and also the level of
criticity expressed by R&D, as a measure of how the design complexity is “mastered”, meaning
that for each new project the component designs is affected only by easily-manageable
modifications.
45
Component% listed, preferred
or partner suppliersR&D Criticity "Light"?
Primary cover 75% 2
Secondary flywheel (raw) 80% 2
Pin 100% 1 YES
Curved Springs 95% 4
Ball bearing 60% 4
Hub 60% 2
Primary flywheel 75% 2
Ring gear 60% 2
Rivet 95% 1 YES
Spacer 95% 1 YES
Inertia ring 90% 1 YES
Seal plastic washer 75% 1 YES
Mass 80% 3
Slider 95% 1 YES
Rolling spacer 80% 3
Roller 100% 2 YES
Stopper 90% 2 YES
Drive plate 65% 4
Make components - - -
"Buy" components
Components for which it is possible to implement the “light” solution are those with at least
90% of suppliers listed, preferred or partner, and with R&D criticity score equal to 1 or 2, and
are identified in Table 7.
According to this the criteria identified above, the updated situation about the number of buy
components to be sourced is the following:
For those components now classified as “light”, the Pre-Soco and Soco process becomes
consistently more agile: Pre-SoCo and SoCo are submitted to Segment Leader validation
without formal slot booking: pre-SoCo is always validated, and if changes are needed, actions
to be completed before SoCo are assigned without going back to activity 1.
All the benefits of this new procedure are illustrated below:
Pre Soco:
Reduction of wait time before the meeting (from 7-11 to 1-7 days);
Criticity Light pre-SoCo/SoCo Standard pre-Soco/Soco
1 5 0
2 3 1
3 0 7
4 0 2
Tabella 1 Identificaton of Light components Table 7 Identificaton of Light components
46
Elimination of waiting time before formal approval, since the Segment Leader will
validate Pre-Soco immediately after having checked it: this allows to save from 0 to 5
waiting days;
Rework elimination: since the low criticity and high know-how level of suppliers, the
Light Pre-SoCo will be always validated. If any minor change is necessary, the Segment
Leader will leave some comments about actions needed, which will be in charge of the
Project Buyer (or, occasionally, to other actors specified);
Reduction of Project Buyer’s workload, since it will not be involved in any Pre-SoCo
meeting.
Soco:
Reduction of waiting time before the meeting (from 7-11 to 1-7 days);
Elimination of waiting time before formal approval, since the Segment Leader will
validate SoCo immediately after having checked it: this allows to save from 0 to 5
waiting days;
Reduction of Project Buyer’s workload, since it will not be involved in any SoCo
meeting.
Effects of the introduction of Light processes are quantitatively analyzed in §3.3.1.
2.3.1.2 One Page
The current procedures for submitting Pre-SoCo to Segment Leader validation require the
Project Buyer to organize the information collected at step 1, and creating a ppt standard
presentation with data taken from the CAA, which is the document created by the Project
manager that contains all the economic information and analysis necessary in order to answer
the RFQ from the customer. It is uploaded by the Project Manager on the MIP, which is the
Project Management internal portal: the Project Buyer can download it in Excel format, and
has to extrapolate the following information for Pre-SoCo preparation: Project Data (Code,
Customer, Platform, Car model, vehicle lifetime), Project Schedule (Milestones), Component
information (Part number, status, lifetime volumes, cost targets).
47
In addition to that, after checking the panel status of potential suppliers, the Project Buyer
has to select which of them to include in the bid list. This Is a crucial step, because two factors
might result in having Pre-SoCo not validated, as outlined from the surveys:
Supplier panel status not updated, meaning that the purchasing strategy at Segment
level has changed without properly notifying the Project Buyer, who will have to
review the bid list, introducing/removing suppliers. This problem is strictly related to
the Segment Leaders’ work, thus it is hard to identify and propose possible
improvements, because it would mean to better analyze the root causes that can lead
to this kind of inefficiency at a level higher than the purpose of this study;
Interviewed Segment Leader highlighted the potential benefits of having more
detailed additional information (with respect to the only the panel status rating) on the
suppliers, such as Financial risk assessment, productivities, production workflow
status and so on. These information is contained in a centralized database, but
retrieving the information to be put in the Pre-SoCo presentation would lead to
additional workload for the Project Buyer, who will spend NVA time just looking for
information, copy and paste it into the ppt presentation.
The current procedure for submitting SoCo to Segment Leader validation requires the Project
Buyer to collect the offers from the suppliers to which has sent the RFQ (activity 6), compare
and analyze the cost breakdowns (activity 7a, or 7c in case of Designer Supplier), and, after
preliminary design validation, to perform negotiation in order to ensure good profitability
indicators , that means, to negotiate a final unit cost lower than the targets indicated before in
Pre-Soco ( taken from CAA), a Long Term Agreement (lifetime annual % unit price discount)
and tooling price.
After having finalized negotiation with all the suppliers RFQed, then the Project Buyer has to
make an analytical comparison in order to individuate the best one(s), and propose one (or
two, in case of double sourcing) suppliers to award, after Segment Leader validation occurring
at SoCo.
All these information are shown in a standard ppt presentation, which has to be uploaded on
Purchasing portal (PuMa) before SoCo.
48
From the surveys it results that there is a remarkable discrepancy between In-process time
and Core process time for the activities 2 - Pre-SoCo preparation and 10 - SoCo preparation;
according to component criticity, 1 hour of work/component is labeled as NVA for SoCo
preparation, while it also increases up to 1.5 hours in case of SoCo. This discrepancy is due to
the fact that “the time spent in retrieving, checking, copying and pasting data from CAA and
online panel status database is frustrating, and also having people continuously creating,
updating, downloading, re-formatting and uploading in other portals is extremely time-
demanding, but essentially useless” (sentence taken from a questionnaire compiled by a
Senior Project Buyer).
Given the high strategic importance of SoCo in terms of project profitability (well highlighted
in the surveys), all the proposed improvements will aim at reducing the NVA time spent on
activities, without trying to reduce the probability that SoCo is not validated (thus, the
objective in this case in not to reduce the % rework, but rather to create a standard tool that
allow even to improve the quality/amount of information on which such important decisions
are taken, reducing at the same time the amount of NVA effort spent by Project Buyer (and
also to shorten the elapsed time of the process).
At the moment in which this study is performed, the company’s internal IT is implementing a
better connection between the purchasing portal, Puma, and the project management portal,
MIP. This could allow to automatically duplicate, for each buy component, CAA values of
purchasing interest (such as volumes, targets, etc.), which have been uploaded on MIP by the
Project manager, directly to the corresponding BOM on Puma. This means, once the project is
created on Puma by the Project Buyer, with all BOM components updated (name, part
number), the corresponding values necessary for Pre-SoCo are automatically filled-in.
The technical aspects of this activity are out of the scope of the study, since the objective is to
propose a solution capable to exploit the opportunity coming from such technological
improvement, and to show the potential impacts in terms of elapsed time and workload
reduction.
The proposed solution is to create a unique, standard Excel document for both Pre-Soco and
SoCo, on which some information are automatically filled in by the system, other info have to
be filled by the Project Buyer, and some calculations and analysis are automatically displayed.
49
The document is divided into 4 sections, that will contain all the information currently shared
between Pre-SoCo and SoCo presentations (see ANNEX I):
1) General information: Project and Component Generic information such as Project Data,
Schedule, lifetimes volumes, component general information. This section is entirely
automatically filled, with all the information taken from the CAA uploaded on MIP.
2) Pre-SoCo summary: is made of two parts:
a) List of supplier selected and related performance indicators (new information
not included in Pre-SoCo presentation, but that is considered valuable from
Segment Leaders (as it results from surveys) : the Project Buyer only has to
select the suppliers, and all the information is automatically filled in from the
centralized database.
b) Targets Setting automatically filled in from CAA.
3) SoCo summary : For each Supplier selected, all the related cost breakdown voices, Long
Term Agreement and Tooling price cells are filled in. Here, another effective
improvement proposal is to let the supplier directly answer the RFQ on Puma portal: in
this way, the system can automatically fill in the respective column, making the
effective Project buyer contribution such negligible that in the new improved sourcing
process activities 7a - Offer collection and 7c -Commercial offer collection are
eliminated. This goes into the direction suggested by the indication coming from the
surveys: regarding the abovementioned activities, a 0.5h/component gap between In-
process time and Core process time emerged. The automatic fill in of quotations and
preliminary analysis allow to cut not only the former, but also the latter time (for the
sake of simplicity, we assume that the whole Project Buyer workload on these
activities drops to 0).
Of course, the Project Buyer will perform negotiation and modify the values until the
One Page is ready to be submitted for SoCo approval: this timing is allocated to activity
9 – Negotiation.
4) Sourcing decision summary: selected supplier & economic performance versus CAA
target. Once the previous section is completed, and negotiation is performed, the file
automatically calculates which supplier has the best economic offer.
50
The One Page showed in ANNEX I has been created with the support of one Senior Project
Buyer, and it is only indicative of which information should be contained in each section and,
moreover, each cell has been given a different color according to how the information will be
filled in. Basically, we took the information that in the AS-IS configuration are required to be
put inside the .ppt presentations made by Project buyer, we put them all together in the same
file (forming the four sections) and we asked the Project Buyer to tell which of the
information could be automatically filled in from the Project Management portal, assuming
that the connection with the Purchasing portal is implemented. The result is a document with
5 different types of cells: those automatically filled (info taken from project management
portal), those filled manually by Project Buyer, those automatically calculated, those which
contain pre-defined values to be selected and finally those which automatically take the
values from suppliers’ RFQ directly uploaded on Purchasing portal.
All the benefits of the One Page tool introduction are summarized below:
Reduction of Project Buyer workload and, as a direct consequence, also of total
Elapsed time, for activities 2 – Pre-SoCo preparation and 10 – SoCo preparation, which
will be translated , inside the TO-BE process, respectively into 2 – One Page generation
and 10 – One Page SoCo update;
Elimination of activities 7a - Offer collection and 7c -Commercial offer collection,
impacting both Elapsed time and Project Buyer workload, and avoiding over-
duplication of RFQ data (in the original process, the Project Buyer collects the offers
received by e-mail from suppliers, creates its own analysis file, reports data into them
in order to evaluate the offers, and then copies again the final values inside the ppt
SoCo presentation);
Giving the access to suppliers to purchasing portal in order to fill the standard RFQ
template will cut the time necessary to collect the offers: this is in line with the
information provided by interviewed suppliers, that express the need to have a better
and more immediate procedure for being involved in the RFQ mechanism. This means
that, while in the AS-IS process, the maximum waiting time of activity 7a - Offer
collection is 20 days, with the new configuration this time is reduced to 15 days, and it
is considered as the waiting time before activity 8a – Design Review (since now the
supplier completes online not only the VRF with the technical offer, but also, at the
51
same time, sends the economic offer directly on the purchasing portal). The same
happens for activity 7c – Commercial offer collection: the associated waiting time (10
days) is “absorbed” by the waiting time introduced for TO-BE activity 9 - Negotiation (5
days).
Effects of the introduction of the One Page are quantitatively analyzed in §3.3.2.
2.3.2 Technical specifications form
One of the most critical issues emerged during the study of the sourcing process are the
different timings related to components provided by Designer Suppliers (in particular, curved
springs).
That’s because of several reasons, that are collected through questionnaires filled by R&D site
manager with the help of some experienced R&D team members, that can be summarized as
below:
Technical specifications are sent by email to suppliers: this can be confusing, especially
because of the several interactions with supplier that are required. The risk is to lose
information, or not update it properly, resulting in errors and design inaccuracies that,
if not detected, may cause consistent delays later on in the process. Moreover, having
more suppliers to manage, the introduction of a standard format allowing to give to
suppliers the same information in the same order would simplify R&D’s work when
preparing the functional specifications request.
Necessary bench tests for design validation are extremely time-consuming: a lot of
steps are required, and the overall testing phase requires at least 1.5 months. This is
the reason why sourcing process for these components must be completed well in
advance with respect to the rest of the project, but often happened that something
went wrong, and the whole test phase had to be repeated, since most of these tests are
sequential, and if the component breaks before the end, the whole process must be
started from the beginning. As a consequence of that, the whole project delayed
because validation of these components did not meet planned schedule: from internal
data, it result that 20% of projects missed the “Design freeze” milestone only because
52
of a delay in spring design validation. When suppliers and R&D are asked the reasons
why this happens, the answers go in the same direction: if only the required test to be
performed later on for design validation were shared with the suppliers at the moment
of sending the functional specifications, with only a few precautions the component
can be designed in order to best fit with the required tests.
With the help of R&D experts, a list of all the macro-information areas that have to be shared
with the designer supplier in order to prevent (or mitigate) the abovementioned issues has
been defined, for springs, that are one of the two components provided by Designer suppliers:
Functionalities and related performance criteria
Technical requirements and related performance criteria
Tests to be performed
Quality requirements
Banned or regulated material indications
General requirements
Particular requests
Drawings and graphs plotting the various critical parameters.
The document has effectively started to be implemented as a standard at Site level. An
example is reported in ANNEX II.
2.4 The improved process (TO-BE)
After having detailed all the proposed improvements individuated, it is possible to show the
TO-BE process.
Figure 14 illustrates the scheme of the improved process: the most evident changes with
respect to the AS-IS configuration are the introduction of the Light processes for Pre-SoCo and
SoCo, and the elimination of activities 7a – Offers collection and 7c – Commercial offers
collection.
The different path for Designer suppliers components is maintained, and all the other effects
of proposed improvements appear at timing level, and will be analyzed in the following
chapter.
53
Project Buyer
1. Info collection &
suppliers pre-selection
Project Buyer
2. One Page generation
CAA, VPSP status
Suppliers «Eligible» and
product exists?
Segment Leader
3i. «Light» Pre SoCo
Segment Leader + PB
3. Standard Pre SoCo
YES
NO 12.Pre Soco validated?
R&D
4a. Technical specifications
+ drawings
Project Buyer
5. VRF preparation
R&D
4b. Functional specifications
NO
Project Buyer
6. RFQ
R&D
7. Technical Offer
collection
R&D
8a. Design Review
R&D
8a. Technical Design Review
Preliminar design validated?
NO
Preliminar design validated?
NO
A
YES
A
YES
Project Buyer
9. Negotiation
YES
Suppliers«Eligible»
and product exists?
Segment Leader
11i. «Light» SoCo
Segment Leader + PB
11. Standard SoCo
YES
NO
13. Soco validated?
Project Buyer
10. One Page SoCo Update
NO
Test Team
Prototyping and bench
tests
DESIGN FREEZE
Designer suppliers components
Figure 14 TO-BE Sourcing process scheme
To conclude, Table 8 shows the TO-BE process breakdown, with a description of each activity,
the indication of the person involved, inputs and outputs. The acronyms are the same used for
the AS-IS process breakdown.
54
Activity Description of the activity R S Inputs OutputsProject scope, timing, project
organization, resources, product
definition, process definition,
sourcing plan, financial status
BOM updloaded on Puma
The new project is created on Puma (volumes,
extraction of buy components, put initial targets
with time evolution for productivity, tooling cost
forecasted).
BOM insertion in Puma format
PB CAA All buy components initialized on
Puma
1Info collection & supplier pre-
selection
Target setting, cost model, sourcing strategy,
negotiation tacticts, timing;
Pre-selects suppliers to be RFQed based on VPSP
status for the Categories/ Technologies as updated
by the GSD/SL in PuMa, anticipates bundling
opportunities (if volumes are high)
PB SL, SQA, PMPuma BOM, VPSP status set by
SLBid list
2 "One Page" generation
Generate the "One Page" out of Puma template,
fills the section related to Pre-SoCo (information
related to Target Setting, Cost Model, proposed
Sourcing strategy and timing).
PB Step 1One Page document uploaded on
Puma
3 Standard Pre-SoCo
-Validation of Bid List or remove pre-selected
suppliers or includes additional “Eligible”
suppliers.
-Validation of cost model information to Project
Buyer and validates target settings.
-Suggestion or challenge of possible Bundling
Opportunities.
- Worldwide strategy definition for the specific
component
SL
PB Step 2
3i "Light" Pre-SoCo
If the supplier is "Eligible" and the "Product Exists",
then the PB can submit the One Page to SL without
formal slot booking. SL checks all the issues as for
standard Pre-SoCo, but the Light Pre SoCo is always
validated: if there are some changes to be made,
they are highlighted by the SL, but are minor
actions that do not require to repeatagain all the
activities from 1.
SL PB Step 2
4aTechnical specifications +
drawings to supplier
R&D provides drawings with technical
specifications (materials, critical parameters,
materials, treatments…)
R&DDrawing and updated technical
specifications sent to suppliers
4bFunctional specifications to
supplier
R&D provides the functional specifications to
supplier, necessary in order to make design
proposals, on the new CDC file
R&D CDC sent to suppliers
5 VRF preparation
PB is in charge of completing his part and, after
Logistics, Quality and R&D have completed theirs,
to send it to the supplier
PB
Logistics
Quality,
R&D
VRF sent to suppliers
6 RFQ
Send invitation letter, volumes, VRF, drawings,
SOP date and other project milestones.
Suppliers signs the VRF and answer the RFQ
directly on Puma, filling the cost breakdown: this
will be automatically fille inside the "One Page".
This allow to have an immediate offer comparison,
avoiding the activities "Offer collection" and
"Commercial Offer collection"
PB VRF, project data on Puma
7 Technical offers collection
Collection of technical offers coming from the
various suppliers, whith different preliminar
design proposals
R&DVRF signed by supplier +
technical proposal(s)
8a Design review
Discuss about technical issues, modifications,
improvement suggestions between supplier and
Valeo's R&D, until having supplier full aware of
every detail of preliminary design that is validated.
This acitivy can be reiterated until reaching a full
undertanding between manufacturer and Valeo's
R&D.
R&D SQA , PB Step 4a
8b Technical design review
R&D reviews the various preliminar design
proposed, discusses with the supplier, and if the
preliminary design is not validated then another
technical offers is submitted by suppliers, until
design is validated (=accepted).
R&D Step 4b
9 NegotiationNegotiation of prices, productivity, discounts,
business linkPB SL
Offers, project targets, Group
rules
10 "One Page" SoCo update
Creation of a standard presentation showing
offers, signed drawings, VRF signed
Panel compliance Criteria, Supplier RFQ analysis
PB
One Page document from Pre-
Soco is update wth the offers from
suppliers
KICK OFF
55
Table 8 TO-BE Sourcing process breakdown
11 Standard SoCo
Meeting with the SL, during which all the Soco
information in the "One Page" section are
reviewed.
If all is OK, then the SoCo must be validated by SL.
SL
PB Other PTMs One Page, VRF, negotiation
11i "Light" SoCo
If the supplier is "Eligible" and the "Product Exists",
then the PB can submit the One Page completely
filled to SL without formal slot booking. SL checks
all the issues as for standard SoCo, but the Light Pre
SoCo is always validated: if there are some changes
to be made, they are highlighted by the SL, but are
minor actions that do not require to repeatagain
all the activities from 1.
SL
Other PTMs One Page, VRF, negotiation
12 Pre SoCo validated The SL validates the Standard Pre Soco SL Step 3Validated bid list and sourcing
strategy
13 SoCo validated The SL validates the Soco SL Step 11Validated bid list and sourcing
strategy
Prototyping and bench tests
The supplier designs and/or build prototypes for
testing.
The work continues until the component design is
compliant with all tests
Test
teamSQA Step 8a/8b
Design freeze = Component with
all it features fully compliant with
customer requirements.
All components have successfully
passed all bench testsDESIGN FREEZE
56
CHAPTER 3
After having introduced and discussed Value Stream Mapping procedures in order to detect
and isolate the main sources of waste inside a process, the relative application to a real case,
and having proposed some improvements based on the results of the previous considerations,
now the focus will be on the creation of a model/tool capable to quantitatively assess their
impact and effectiveness. A general mathematical model will be illustrated, showing the step-
by-step calculations that allow to define some meaningful indicators, that are, Total Elapsed
Time (TET), Total Process Elapsed Time (TPET), Total Process Time (TPT) and resources
utilizations (µ).
3.1 The mathematical model
This sections is dedicated to define a model that has been elaborated in order to analyze the
impacts of the proposed improvements that come from the application of Value Stream
Mapping methodology to a given process: it takes into account the level of activity
breakdown performed, and the data on timings collected through questionnaires (but, of
course, data could come from other sources, like direct measurements, probability
distributions, etc. The better the quality of estimations, the better the model will be
representative of the real process).
The process is divided into i steps, and to each of them are associated one or more activities,
identified with k. Furthermore, to each activity is associated a resource j (1=Project Buyer,
2=R&D, 3=Segment Leader) and a level l = 1 ,…, ni (where ni is the number of level associated
to Step i). The meaning of the level l will be explained later on in this section.
From surveys made with the VSM analysis, In-process times pt (k,z) (time, in hours, that the
resource j associated to the activity k spend to complete the activity itself, depending on the
criticity level z of the component) Rework Process times rt(k,z) (in hours) and Probability of
rework r(k,z) are collected. Moreover, also indications on the waiting time before some
activities are collected: wt(k,z) (in days) is the time a component with criticity z has to wait
before being processed, and rwt(k,z) is the equivalent for reworks.
Furthermore, survey also collected another important time, which has been helpful in order to
individuate which activities were associated the highest NVA times: it is the Core-Process
57
time. The difference between In-process time and Core-process time is an indicator of how
much NVA time and effort is spent by the resource on the activity, and it has been useful in
order to estimate the In-Process times for the TO-BE process.
With all this information, now it is possible to define some variables that are useful to analyze
and compare the efficiency in terms of time and resource overload of the 2 processes:
Activity In-process Time and Rework Time;
Activity Total Process Time ;
Activity Elapsed Time and Rework Elapsed Time;
Activity Total Elapsed Time;
Step Total Elapsed Time;
Total Process Elapsed Time.
Let’s now go into further details.
3.1.1 Activity In-process time PT(k) and Rework time RT(k)
First of all, we define the activity In-process time PT(k) (in order to avoid a confusing
notation, we will not indicate, as it would be expected, PT(k,j), simply because, with an
appropriate level of process breakdown, to each activity k one and only one resource j is
associated, thus there is no risk of misinterpretation.
Given n(z) = number of components with criticity level z, the Activity In-process time is
defined as:
𝑃𝑇(𝑘) = ∑ 𝑝𝑡(𝑘, 𝑧) ∙ 𝑛(𝑧)
𝑧
In our case, PT(k) is expressed in hours.
In analogy to what discussed above, it comes the formula for the Activity Rework Time:
𝑅𝑇(𝑘) = ∑ 𝑟𝑡(𝑘, 𝑧) ∙ 𝑟(𝑘, 𝑧) ∙ 𝑛(𝑧)
𝑧
In our case, RT(k) is expressed in hours.
58
3.1.2 Activity Total Process Time TPT(k)
Once calculated PT and TPT, it is possible to calculate the Total Process Time for the activity k,
which is the total time of effective work spent by the associate resource j, which is simply:
𝑇𝑃𝑇(𝑘) = 𝑃𝑇(𝑘) + 𝑅𝑇(𝑘)
Let’s suppose that, TPT(k) is expressed in hours.
3.1.3 Activity Elapsed Time ET(k) and Rework Elapsed Time RET(k)
Once we have calculated the activity In-Process time PT(k), it is possible to find the total
amount of time necessary for activity completion (meaning, all components of one project
have been processed), taking into account the waiting times:
𝐸𝑇(𝑘) = 𝑚𝑎𝑥𝑧𝑤𝑡(𝑘, 𝑧) + 𝑃𝑇(𝑘)
ℎ
Where h is the number of working hours/day; it comes that ET(k) is expressed in days.
The expression 𝑚𝑎𝑥𝑧𝑤𝑡(𝑘, 𝑧) means that the total waiting time of the activity is given by the
maximum waiting time among all the components that are processed: it happens that, for
some activities, the waiting time is different depending on the criticity level z of the
component. Since we are considering the Elapsed Time as the time to process all the
components of a project, the total waiting time will be equal to the bottleneck, i.e. the
maximum waiting time among all components.
In analogy to what discussed above, it comes the formula for the Activity Rework Elapsed
Time:
𝑅𝐸𝑇(𝑘) = 𝑚𝑎𝑥𝑧𝑟𝑤𝑡(𝑘, 𝑧) + 𝑅𝑇(𝑘)
ℎ
3.1.4 Activity Total Elapsed Time TET(k)
In analogy to the activity Total Process Time TPT(k), it is possible to define the Total Elapsed
time as the total time from when activity k is “enabled” (it could start, if other factors
59
wouldn’t cause wait times) to the effective activity completion, considering that one or more
components may be subject to reworks:
𝑇𝐸𝑇(𝑘) = 𝐸𝑇(𝑘) + 𝑅𝐸𝑇(𝑘)
It is immediate to notice that, with the previous assumptions on units of measure, TET(k) is
expressed in days.
3.1.5 Step Total Elapsed Time STET(i)
In order to understand how the STET(i) is calculated, it is necessary to give some
clarifications. First of all, it is important to remind the objective of this analysis, that is, to
evaluate and quantify the effects of the proposed process improvements in terms of total time
necessary to complete the sourcing process for all the components that constitute a project:
this time is measured as Total Process Elapsed Time (TPET).
Another issue is related to the TPET calculation: having a look at the process scheme, and
reasoning in terms of total time necessary to complete a determined activity for all the
components of a project, it is possible to notice that, once evaluated the Total Elapsed Time
necessary to complete every single activity, the Total Process Elapsed Time for the process is
NOT given simply by the algebraic sum of all these times. That’s because, by doing so, we
would likely over-estimate the total time necessary to complete the whole sourcing process
because we are ignoring the fact that some activities can be done in parallel by different
resources.
For example, for what concerns the AS-IS configuration, there is only one part that can be
performed in parallel, that is, on one side the Project Buyer can perform activity 5 - VRF
Preparation, while at the same time R&D can work on activities 4a and 4b. This is why it is
necessary to introduce what we will call Steps, indicated with the letter i. According to this
notation, these 3 activities are grouped into the same step i=5, and each of them will have a
different level of index l. The Total Elapsed Time of two (or more) activities k belonging to the
same Step i, and with the same value of l, have to be summed, and the Total Elapsed Time of
the Step (STET(i)) will be the maximum among all the sums of Elapsed Times of the activities
with the same level l.
It follows that the formula for the calculation of the STET(i) is:
60
𝑆𝑇𝐸𝑇(𝑖) = max ( ∑ 𝑇𝐸𝑇(𝑘) ,
𝑘,𝑙=1
∑ 𝑇𝐸𝑇(𝑘) ,
𝑘,𝑙=2
… , ∑ 𝑇𝐸𝑇(𝑘)
𝑘,𝑙=𝑛𝑖
)
Where ni is the number of levels l associated to Step i.
Coming back to the example, in order to calculate the Total Elapsed Time of this step
(STET(5)), it is necessary to take into account that, since activities 4a and 4b are performed by
the same resource, we have to associate them to the same level l=1. The maximum between
this calculated time and the TET necessary for activity 5 (performed by Project Buyer) is the
Total Elapsed Time for the step i=5.
Once noticed this effect, it is clear that the more we can group and parallelize activities, the
higher the benefits in terms of TPET. This is exactly what it has been tried to implement in the
improved process, where the number of Steps i that group more than one activity is increased
from 1 to 3, thanks to the introduction of Light Pre-SoCo and SoCo. Of course, the effects of
this parallelization are barely noticeable if they are not supported by In-process time and/or
Waiting time reductions (done, in our case, with the introduction of the One Page template).
3.1.6 Total Process Elapsed Time (TPET) and resources utilization µ
Finally, it is possible to write down the formula for the calculation of the Total Process
Elapsed Time:
𝑇𝑃𝐸𝑇 = ∑ 𝑆𝑇𝐸𝑇(𝑖)
𝑖
This value will be the estimation of the total time necessary to complete a process, taking as
perspective the whole project.
Moreover, it is possible to define another performance indicator, related to resources
overload: the utilization µj.
First of all it is necessary to calculate the TPT(j) of all the activities k associated to resource j:
𝑇𝑃𝑇(𝑗) = ∑ 𝑇𝑃𝑇𝑗(𝑘)
𝑘
61
The utilization of resource j is then defined as:
µ𝑗 = 𝑇𝑃𝑇(𝑗)
𝑇𝑃𝐸𝑇
With µj ∈ [0,1].
3.2 Application of the model to Sourcing Process
After having illustrated a model, it is time to apply it to the two configurations of our studied
process: AS-IS and TO-BE. For the purpose of identifying the overall results in terms of
general indicators, in this section we will only look at the two configurations as if they were
two distinct processes, without taking care of i) which improvements have been proposed, ii)
why they have been proposed and iii) the impact of each improvement on the activities it is
related to. These issues will be discussed later on in §3.3. That’s because now the objective is
only to show how the model allow comparisons between two processes, of which one results
from the application of some improvements (in terms of activities In-process times and
waiting times) to the other one.
3.2.1 AS-IS process
In our case, the activity breakdown led to identify 18 activities (k =18), and 16 steps (i =16).
We have 2 resources involved in process activities, Project Buyer (j=1) and R&D (j=2).
Within each step i, one or two levels l are assigned, depending on whether the activities can be
performed in parallel or not.
The associations of the AS-IS process are shown in Table 99.
Each project entails the processing of 18 components, divided into 4 criticity categories: thus,
we have z =1,…,4, n(1)=5, n (2)=4, n (3)=7, n (4)=2.
The average working day is made of 8 hours, thus h=8 hours/day.
ANNEX III shows the Excel table that has been created in order to perform all the calculations.
The results in terms of Total Process Elapsed Time (TPET), resource Total Process Time
TPT(j) and utilization µj are shown below:
62
3.2.2 TO-BE process
The proposed improved process is broken down into 18 activities (k=18), but in this case the
introduction of the Light Pre-SoCo and SoCo led to 13 steps (i = 13).
The associations of the TO-BE process are shown in Table 9.
As for the AS-IS process, each project entails the processing of 18 components, divided into 4
criticity categories: thus, we have z =1,…,4, n(1)=5, n (2)=4, n (3)=7, n (4)=2.
The difference, in this case, is that it is necessary to distinguish between light and non-light
components, identified with nlight(z) and nnon-light(z).
z nlight(z) nnon-light(z)
1 5 0
2 3 1
3 0 7
4 0 2
Based on that, the formulas for calculating PT(k) and RT(k)for activities k=3 (“Standard Pre-
SoCo) and k= 16 (“Standard SoCo”) changes as below:
𝑃𝑇(𝑘) = ∑ 𝑝𝑡(𝑘, 𝑧) ∙ 𝑛𝑛𝑜𝑛−𝑙𝑖𝑔ℎ𝑡(𝑧)
𝑧
𝑅𝑇(𝑘) = ∑ 𝑟𝑡(𝑘, 𝑧) ∙ 𝑟(𝑘, 𝑧) ∙ 𝑛𝑛𝑜𝑛−𝑙𝑖𝑔ℎ𝑡(𝑧)
𝑧
While, for activities k = 5 (“Light Pre-SoCo) and k = 17 (“Light SoCo”), since in this case the
resource Project Buyer is not more involved, Elapsed Times are simply given by the maximum
TPET [days, months] TPT(PB) [h], µPB TPT(R&D) [h], µR&D
168,2 302,1 275,5
8,4 0,22 0,20
63
time it is necessary for having Pre-SoCo and SoCo formally validated by the Segment Leader
(5 days, according to the data collected through questionnaires).
Table 9 Model associations for AS-IS and TO-BE Sourcing process
ANNEX IV shows the Excel table that has been created in order to perform all the calculations.
The results in terms of Total Process Elapsed Time (TPET), resource Total Process Time
TPT(j) and utilization µj are shown below:
TPET [days, months] TPT(PB) [h], µPB TPT(R&D) [h], µR&D
139,6 215,4 269,5
7,0 0,19 0,24
ID Activity name i k l j ID Activity name i k l j
AS-IS Sourcing Process TO-BE Sourcing Process
2
1
1
1
3
3
2
1
1
2
2
2
1
1
1
3
3
2
1
1
1
1
1
1
2
1
1
1
1
1
1
1
1
1
1
1
13 18 1
3
4
12
16 1
17 2
10 14 1
11 15 1
8 12 1
9 13 1
6 10 1
7 11 1
1
8 2
5 9 1
1
4 1
5 2
6 1
7
13 Soco VALIDATED ?
1 1 1
2 2 1
3
10 One Page SoCo update
11 SoCo
11i Light Soco
8b Technical design review
14 Preliminar design validated ?
9 Negotiation
6 RFQ
7 Technical offers collection
8a Design review
Light Pre-Soco
4a Technical specifications + drawings preparation
4b Functional specifications preparation
5 VRF preparation
18
1 Info collection & Supplier pre selection
2 "One Page" generation
3 Standard Pre-Soco
12 Pre-Soco VALIDATED ?
3i
9
10
11
12
13
14
15
16
17
13
14
15
16
7
8
9
10
11
12
5
5
6
7
6 8
1
2
3
4
1
2
3
4
2
2
1
1
1
3
1
1
1
2
1
2
1
1
1
3
2
2
10 SoCo preparation
11 SoCo
13 Soco VALIDATED ?
8b Technical design review
14 Preliminar design validated ?
9 Negotiation
7b Technical offers collection
7c Commercial offers collection
8a Design review
5 VRF preparation
6 RFQ
7a Offers collection
12 Pre-Soco VALIDATED ?
4a Technical specifications + drawings preparation
4b Functional specifications preparation
1 Info collection & Supplier pre selection
2 Pre-Soco preparation
3 Pre-Soco
64
3.2.3 Analysis of results
The model output comparison of the two processes gives evidence that the introduction of the
improved TO-BE Sourcing process determines:
TPET reduction: -17%
TPTPB reduction: -29%
TPTR&D reduction: -2.2%
µPB reduction: -13.6%
µR&D increase: +20%
The R&D utilization increase is justified by the fact that, in percentage terms, TPT(R&D)
decreases less than TPET (2.2% < 16%); the opposite happens for the Project Buyer
utilization.
This result is totally acceptable because of the assumptions made for the study: the R&D is
not a critical resource since he starts working on the various project components right after
project kick off (when also the Sourcing process initiates), and it is not involved in other time-
consuming activities out of those that have been included into the Sourcing process: for the
R&D activities belonging to the Product Development process, other specialized teams will
take charge of the project. Thus, for the sake of simplicity, we modeled the presence of the
R&D member as a single resource with acceptable levels of utilization µ lower than 0.8 (this
value is taken as a reference in order to consider all the eventual other activities that the
resource has to perform in parallel to the sourcing process ones).
The project Buyer, instead, is a scarce resource, since he working on more projects in parallel,
at different phases of their life: thus, it can happen that he is performing the sourcing process
for components belonging to different projects, and at the same time he is also performing
activities out of the sourcing (i.e. following the tool launch, or the production ramp-up).
According to the surveys made among Project Buyers, it emerged that they estimated the total
available time for sourcing activities between 40 and 45%, meaning that a µPB < 0.45 can be
considered as good (of course, the lower the better).
65
3.2.4 Model limitations
In order to handle and interpret correctly these numbers, some important remarks and
considerations must be taken into account:
1) The utilization µPB obtained from the model cannot be directly compared with the time
the Project Buyer can dedicate to sourcing activities, because the model is static: it
does not take into account the fact that, while the sourcing process for components of a
new project is on-hold, new projects can start, or maybe there are still components
belonging to older projects still in the process.
2) The model does not take into account that, once a sourcing process is started, the 18
components are “spread” among the various activities, depending on process times
and probabilities of rework. The model, instead, sees the 18 components as a “block”
that moves from one activity to the next one as it were a single entity: this, of course,
makes the Elapsed Time be over-estimated and, as a consequence of that, also the
TPET results inflated.
This issue is particularly limiting in the specific process under study because, for
components made by Designer Suppliers (those with z=4), supplier selection (SoCo)
must be done well in advance with respect to all the other components, because of the
higher time necessary to perform all the bench tests to meet “Design Freeze” milestone
on time. Unfortunately, component priorities and time to complete the sourcing
process for the two critical components cannot be neither modeled nor detected by the
formulas previously introduced.
3) The model is deterministic: all time values are approximated with the simple mean.
Considering that on average 3 new projects are initiated each year, this means that one new
project arrives every 4 months. Based on TPET calculated by the model, each sourcing process
lasts 0.66 years (8 months): this means that, on average, both PB and R&D are working on 2
projects at the same time. This would mean that the utilization should be multiplied by a
factor of 2 in order to assess the effective resource workload. This leads to estimate that, in
normal conditions, the Project Buyer has to dedicate 44% (AS-IS configuration) and 38% (TO-
BE configuration) to sourcing activities, while the R&D from 40% (AS-IS configuration) to
48% (TO-BE configuration).
66
The model is effective in outlining the effects of the introduction of the TO-BE Sourcing
process with respect to the current one. Moreover, it is quite general and can have different
applications to different processes, starting with very few data to be collected.
Up to now, all the main drawbacks and limitations to be carefully taken into account have
been outlined, together with some considerations on the model predictability effectiveness.
For the purpose of this study, a step further will be made, considering the main limitations of
the model used to analyze the process, that are, on one side, that it is static and, on the other
side, it is fully deterministic. Moreover, the necessity to assign priorities to most critical
components and the need to monitor the time necessary to complete the Sourcing Process for
Designer Suppliers components pushed in the direction to adopt an alternative tool, capable
to overcome, within certain limits, these downside effects. Here it comes the decision to
implement a simulation model: §3.4 will be dedicated to the simulation procedure and result
analysis, which will be compared to what came out from model application.
In this section we only calculated the overall impact of all the proposed modifications at
macro level (TPET, TPT(Project Buyer), TPT(R&D), µPB, µR&D), taking them as grant. Now
it’s time to enter into the detail of each proposed improvement, showing the impacts each
one of them can bring.
3.3 Analysis of improvements
In Chapter 2, as a result of the application of the Value Stream Mapping methodology, three
major process improvements have been identified and discussed.
Just to recap, they are:
A) Introduction of Light process for Pre-SoCo and SoCo for those components that satisfy
some given conditions;
B) Introduction of the One Page standard format for Pre-Soco and SoCo preparation, and
offers collection from suppliers;
C) Introduction of Technical specifications form for preparation of functional
specifications and communication of them to Designer Suppliers.
The correspondence between AS-IS Sourcing process and improvements is shown in Table 10.
67
Table 10 AS-IS activity - proposed improvement correspondence
The first step in order to make an analysis of the contribution of each of the improvements is
to make an extrapolation and combine some data from Exhibit I and II, in order to show, for
each of the AS-IS activities that are impacted by one of the changes, the differences in terms of
the indicators that are used to perform the analysis (that are, the Activity Total Elapsed Time
and the Total Process Time of resources Project Buyer and R&D): this are shown in Table
1111.
In order to evaluate the effectiveness of each improvement on ever activity that is impacted, it
is necessary to define some percentage indicators:
∆𝑇𝐸𝑇(𝑘)% = 𝑇𝐸𝑇(𝑘)𝐴𝑆−𝐼𝑆 − 𝑇𝐸𝑇(𝑘)𝑇𝑂−𝐵𝐸
𝑇𝐸𝑇(𝑘)𝐴𝑆−𝐼𝑆
∆𝑇𝑃𝑇(𝑃𝐵)% = 𝑇𝑃𝑇(𝑃𝐵)𝐴𝑆−𝐼𝑆 − 𝑇𝑃𝑇(𝑃𝐵)𝑇𝑂−𝐵𝐸
𝑇𝑃𝑇(𝑃𝐵)𝐴𝑆−𝐼𝑆
AS-IS Activity Proposed Improvement
B) One Page
A) Light process
C) Technical specifications form
B) One Page
C) Technical specifications form
8a. Design Review
7c. Commercial offers collection B) One Page
9. Negotiation
10. SoCo preparation
11. SoCo
13. SoCo validation
B) One Page
B) One Page
B) One Page
A) Light process
2. Pre-SoCo preparation
3.Pre-SoCo
12. Pre-SoCo validation
4b. Functional specifications preparation
7a. Offers Collection
7b. Technical offers collection
68
∆𝑇𝑃𝑇(𝑅&𝐷)% = 𝑇𝑃𝑇(𝑅&𝐷)𝐴𝑆−𝐼𝑆 − 𝑇𝑃𝑇(𝑅&𝐷)𝑇𝑂−𝐵𝐸
𝑇𝑃𝑇(𝑅&𝐷)𝐴𝑆−𝐼𝑆
While the total impact is calculated by the ratio:
∆𝑇𝐸𝑇%,𝑇𝑂𝑇𝐴𝐿 𝐼𝑀𝑃𝐴𝐶𝑇 = ∑ 𝑇𝐸𝑇(𝑘)𝐴𝑆−𝐼𝑆𝑘 − ∑ 𝑇𝐸𝑇(𝑘)𝑇𝑂−𝐵𝐸𝑘
∑ 𝑇𝐸𝑇(𝑘)𝐴𝑆−𝐼𝑆𝑘
In analogy are defined total impacts for resources TPT.
Calculations results are shown in Table 12: it is evident to notice that the proposed
improvements have a positive impact on almost all the activities. The only two “red results”
will be investigated when analyzing the impact of B) One Page introduction.
Table 11 Impact of proposed improvements on process activities
Table 12 ∆𝑻𝑬𝑻 and ∆𝑻𝑷𝑻 calculations
AS-IS Activity Proposed Improvement TET(k) TPT Project Buyer TPT R&D
AS-IS 5,7 45,6 -
TO-BE 2,3 18,6 -
AS-IS 29,2 9,6 -
TO-BE 28,7 5,6 -
AS-IS 1,8 - 14
TO-BE 1,3 - 10
AS-IS 33,7 29,5 -
TO-BE 0,0 0,0 -
AS-IS 4,6 - 10,0
TO-BE 2,3 - 8,0
AS-IS 10,3 2,0 -
TO-BE 0,0 0,0 -
AS-IS 16,6 - 132,5
TO-BE 36,6 - 132,5
AS-IS 10,0 80,2 -
TO-BE 15,0 80,2 -
AS-IS 7,1 57,0 -
TO-BE 4,6 37,0 -
AS-IS 29,3 10 -
TO-BE 28,7 6 -
TOTAL AS-IS (activities affected by changes) 146,3 234,0 156,5
TOTAL TO-BE (activities affected by changes) 119,2 147,2 150,5
27,1 86,7 6,0Δ
2. Pre-SoCo preparation
3.Pre-SoCo
12. Pre-SoCo validation
4b. Functional specifications preparation
7a. Offers Collection
7b. Technical offers collection
9. Negotiation
10. SoCo preparation
11. SoCo
13. SoCo validation
B) One Page
B) One Page
B) One Page
A) Light process
8a. Design Review
7c. Commercial offers collection B) One Page
B) One Page
A) Light process
C) Technical specifications form
B) One Page
C) Technical specifications form
AS-IS Activity Proposed Improvement Δ TET(k) [%] Δ TPT Project Buyer Δ TPT R&D
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
TOTAL IMPACT (on activities affected by changes)
B) One Page
A) Light process
C) Technical specifications form
B) One Page
C) Technical specifications form
-28,6%
-20,0%
0,0%
-18,5% -37,1% -3,8%
49,9%
-35,1%
-1,8%
-100,0%
-100,0%
0,0%
-35,1%
-41,4%
-59,2% -59,2%
-1,7% -42,3%
-28,6%
-100,0%
-49,4%
-100,0%
120,8%8a. Design Review
7c. Commercial offers collection B) One Page
9. Negotiation
10. SoCo preparation
11. SoCo
13. SoCo validation
B) One Page
B) One Page
B) One Page
A) Light process
2. Pre-SoCo preparation
3.Pre-SoCo
12. Pre-SoCo validation
4b. Functional specifications preparation
7a. Offers Collection
7b. Technical offers collection
69
3.3.1 Light process introduction
The benefits of the new Light procedure for Pre-SoCo and SoCo are recalled below:
Reduction of waiting time before Pre-SoCo/SoCo meeting (from 7-11 to 1-7 days);
Elimination of waiting time before formal Pre-Soco/SoCo approval: this allows to save
from 0 to 5 days in terms of waiting time;
Pre-SoCo rework elimination: since the low criticity and high know-how level of
suppliers, the Light Pre-SoCo will be always validated.
Reduction of Project Buyer’s workload, since it will not be involved in any Pre-
SoCo/SoCo meeting.
The following table shows the estimated time savings in terms of Elapsed Time and Project
Buyer Total Process Time of the activities affected by Light process introduction:
Δ TET(k) Δ TPT Project Buyer
3.Pre-SoCo + 12. Pre-SoCo validation -1,70% -42,30%
11. SoCo + 13. SoCo validation -1,80% -41,40%
The most evident benefits are obtained in terms of Project Buyer’s TPT. This happens because
the Elapsed Time, as it is measured, is strongly influenced by the time at which the last
component terminates the Pre-Soco or SoCo activities and, since the new Light processes only
apply to 8 out of 18 components, the total elapsed time will always be conditioned by the fact
that non-light components will be processed exactly as they did in the AS-IS situation, that
means, they are affected by a maximum waiting time of 11 days before SoCo meeting, and 3
days for validation (as shown in Figure 15). The same happens also for SoCo. The small
discrepancies between Elapsed time AS-IS and TO-BE is justified by the fact that the effective
Pre-SoCo and SoCo In-process times are reduced thanks to the fact that there is a lower
number of components that will require standard Pre- SoCo/SoCo, but the unchanged
maximum waiting time prevail and dampen the effects of TPT 42% reduction.
70
Figure 15 Maximum Pre-SoCo waiting times AS-IS vs TO-BE
3.3.2 One Page introduction
All the benefits of the One Page tool introduction are summarized below:
Reduction of Project Buyer workload and, as a direct consequence, also of total
Elapsed time, for activities 2 – Pre-SoCo preparation and 10 – SoCo preparation;
Elimination of activities 7a - Offer collection and 7c - Commercial offer collection,
impacting both Elapsed time and Project Buyer workload, and avoiding over-
duplication of RFQ data;
Reduction of time necessary to collect the offers. This means that, while in the AS-IS
process, the maximum waiting time of activity 7a - Offer collection is 20 days, with the
new configuration this time is reduced to 15 days (and allocated as waiting time to
activity 8a - Design Review that, indeed, shows ∆𝑇𝐸𝑇 % > 0. The same happens for
activity 7c – Commercial offer collection, reduced from 10 to 5 days (and allocated as
waiting time to activity 9 – Negotiation, that, again, shows ∆𝑇𝐸𝑇 % > 0).
The following table shows the estimated time savings in terms of Elapsed Time and Project
Buyer/R&D Total Process Time of the activities affected by One Page introduction:
Δ TET(k) Δ TPT Project Buyer Δ TPT R&D
2.Pre-SoCo preparation -59,2% -59,2% -
7a. Offers collection -100,0% -100,0% -
7c. Commercial offers collection -100,0% -100,0% -
8a. Design Review 120,8% - 0,0%
9. Negotiation 49,9% 0,0% -
Activity ID k Activity name R Criticity (z) pt(k,z) [h] PT(k) [h] RT(k) [h] TPT(k) [h] max wt(k,z) [d] ET(k) [d] r(k,z) rt(k,z) [h] max rwt(k,z) [d] RET(k) [d] TET(k) [d] l STET(i) [d]1 1,75 0 02 1,75 0,1 0,253 1,75 0,2 0,254 1,75 0,35 0,251 2,5 0 02 2,5 0,1 0,253 2,5 0,2 0,254 2,5 0,35 0,251 0,5 0 02 0,5 0,1 0,253 0,5 0,2 0,254 0,5 0,35 0,251 - - - - 0 -2 - - - - 0,1 -3 - - - - 0,2 -4 - - - - 0,35 -
1
1
1
1
4,0
5,7
23,2
6,0
4,0
5,7
23,2
6,0
0,1
11,1
3,0
0,0
11,0
3,012 Pre-Soco VALIDATED ? SL4
3 Pre-Soco PB 9 0,6 9,6
2 Pre-Soco preparation PB 45 0,6 45,62
3
1 Info collection & Supplier pre selection PB 31,5 0,6 32,1 0,10,0 3,91 0,0
0,0
11,0
3,0
5,6
12,1
3,0
Activity ID k Activity name R Criticity (z) pt(k,z) [h] PT(k) [h] RT(k) [h] TPT(k) [h] max wt(k,z) [d] ET(k) [d] r(k,z) rt(k,z) [h] max rwt(k,z) [d] RET(k) [d] TET(k) [d] l STET(i) [d]1 1,75 0 02 1,75 0,1 0,253 1,75 0,2 0,254 1,75 0,35 0,251 1 0 02 1 0,1 0,253 1 0,2 0,254 1 0,35 0,251 0,5 0 02 0,5 0,1 0,253 0,5 0,2 0,254 0,5 0,35 0,251 - - - - 0 -2 - - - - 0,1 -3 - - - - 0,2 -4 - - - - 0,35 -1 - - - - - -2 - - - - - -3 - - - - - -4 - - - - - -
4,0
2,3
1
1
2
28,7
1
1
11,6
3,0
5
11,1
3
0
0
11
3
0 0
4,0
2,3
22,7
6,0
5,0
12 Pre-Soco VALIDATED ? SL
3i Light Pre-Soco SL
4
5
3 Standard Pre-Soco PB 5 0,6 5,6
2 "One Page" generation PB 18 0,6 18,62
3
1 Info collection & Supplier pre selection PB 31,5 0,6 32,1 0,0
0,0
3,9
2,3
0,1
0,1
1
5,0
11,0
3,0
AS-IS
TO-BE
71
10. SoCo preparation -35,1% -35,1% -
As it is immediate to notice, in this case the whole effect of Process Time reduction in Pre-
SoCo and SoCo preparation activities directly affects Total Elapsed Time, since, differently
than what discussed for Light process introduction, there are no waiting times that dampen
the effect. As illustrated above, activities 7a and 7c are eliminated(resulting in a 100%
reduction both in terms of TET and TPT) : this means that the waiting time for receiving
technical offer is reversed on activity 8a-Design Review, while the waiting time for receiving
the economic offer is included in 9 – Negotiation. This explains why we have a Δ TET increase
for those 2 activities.
3.3.3 Technical specifications form introduction
The benefits resulting from the application of the standard format for sharing technical
specifications with Designer Suppliers are summarized below:
In-Process time of activity 4b – functional specifications preparation is decreased
from 7 hours to 5 hours;
The maximum waiting time of activity 7b – Technical offers collection (3 days) is
decreased to 1.5 days in the corresponding activity of the improved TO-BE process;
moreover, also the In-Process time necessary for R&D to perform this activity is
reduced from 2 hours to 1 hour.
Consistent improvements in terms of bench tests timing are expected.
The following table shows the estimated time savings in terms of Elapsed Time and Project
Buyer/R&D Total Process Time of the activities affected by the introduction of the technical
specifications form:
Δ TET(k) Δ TPT R&D
4b. Functional specifications preparation
-28,6% -28,6%
7b. Technical offers collection -49,4% -20,0%
3.3.4 Overall improvements impact
After having illustrated in detail all the proposed improvements, it is interesting to sum up all
the combined effects that they bring:
72
It is clear that:
∆𝑇𝑃𝐸𝑇 = ∑ ∆𝑇𝐸𝑇 (𝑎𝑐𝑡𝑖𝑣𝑖𝑡𝑖𝑒𝑠 𝑎𝑓𝑓𝑒𝑐𝑡𝑒𝑑 𝑏𝑦 𝑖𝑚𝑝𝑟𝑜𝑣𝑒𝑚𝑒𝑛𝑡𝑠)
Indeed, in our case we have ∆𝑇𝑃𝐸𝑇 = 168.2-139.6 = 27.1 days, while from above we get that
∑ ∆𝑇𝐸𝑇 (𝑎𝑐𝑡𝑖𝑣𝑖𝑡𝑖𝑒𝑠 𝑎𝑓𝑓𝑒𝑐𝑡𝑒𝑑 𝑏𝑦 𝑖𝑚𝑝𝑟𝑜𝑣𝑒𝑚𝑒𝑛𝑡𝑠) = 146.3 − 119.2 = 27.1 days.
The following table shows the percentage reduction in terms of TET and TPT considering only
of the activities affected by proposed changes:
The overall impact of changes on the whole Sourcing process (considering also the activities
that are not affected at all by any proposed improvement) has already been calculated in
§3.2.3: of course, the ratios differ with the ones calculated taking into account only activities
affected by changes (those reported in Table 12) just because in the case of the whole
sourcing process, as denominator of the ratio we have to consider the TPET (which, of course,
is > sum of TET of activities affected by improvements).
Overall impacts on the Sourcing process are recalled below:
3.4 The simulation model
In order to build a simulation model for the process, the software selected is Arena, which is
based on an embedded language called SIMAN (SImulation Modeling ANalysis). This language
does no require to write down code lines, because the entire simulation model creation
process is graphic, visual and integrated.
TET(k) [days] TPT PB [hours] TPT R&D [hours] TET(k) [days] TPT PB [hours] TPT R&D [hours]
58,5 19,6 - 57,4 11 -
83,4 214,3 132,5 58,5 135,8 132,5
4,5 - 24,0 3,6 - 18,0
146,3 234,0 156,5 119,2 147,2 150,5
AS - IS TO-BE
A) Light Process
B) One Page
C) Technical specifications form
TOTAL
ΔTET(k) [days] ΔTPT PB [hours] ΔTPT R&D [hours]
1,8% 41,8% -
29,8% 36,6% 0,0%
21,2% - 25,0%
-18,5% -37,1% -3,8%OVERALL REDUCTION
A) Light Process
B) One Page
C) Technical specifications form
Δ TPET -17 %
Δ TPT Project Buyer -29 %
Δ TPT R&D -2,2 %
73
The step-by-step description of how the model has been built is out of the scope of this work.
Of course, modelling with Arena requires some basic knowledge on how the software works
and behaves, the relations between entities, variables and attributes, the definition of
espressions and sets:instead of providing a detailed illustration of all the aspects of the AS-IS
and TO-BE Arena models, we prefer to give an overall idea on the “physical” structure of the
model (modules and entity flows), and then focus on how the various timings (arrival times,
process times, waiting times) are modelled, since this is the greatest value added with respect
to the mathematical model introduced before.
Each project is modeled as an entity that, as soon as it enters the systems, is divided into the
18 components: each of them will be given a criticity level z, through the attribution of an
attribute called Critic. Another important and useful attribute is R, which is initialized to 1,
and it is used in order to track, for each component, the whether it is at the first work or it is
being “reworded” and, if so, how many times it happened. As we will see later on, the
definition of this two atttribute is useful in order to model time functions which depend on
both the component criticity and the number of times a component has been “reworked”.
After that, the Sourcing process can start, and each of the 18 activities is modelled through a
PROCESS block: here we have the first, great improvement with respect to the mathematical
model, since Arena allows to assign a priority rule to the activity queues. Thus, the priority
rule selected is “highest attribute value”, meaning that, among all the components waiting to
be processed in a certain activity, the first will be the ones with the highest value of Critic
attribute. This makes it possible to model the fact that the two components provided by
Designer Manufacturers complete the Sourcing process well in advance with respect to the
other ones, and it will also be possible to estimate this time, in order to check if it is consistent
with the time required to perform bench tests (from 1.5 up to 3 months).
Another important aspect to model are waiting times: this is made through a DELAY block,
they are modeled using Exponential or Uniform distributions. This allow to introduce that
level of stochasticity on waiting times that was completely missing in the mathematical
model. Details on all the timing definitions are given for the two configurations (AS-IS and TO-
BE).
Considering that all data on timing have been collected through questionnaires created for
the Value Stream Mapping, the amount of information did not allow to make any inference in
74
order to model process times with statistical distributions: an attempt to do so, with the data
collected for this study, this would be misleading and would not be significative. Moreoer, it is
important to remember that the objective of Value stram Mapping is not to create a a running
model that perfectly mirror the real process, but rather to idntify and estimate the average
impacts of many waste sources, and propose some improvements which can be, again,
quantitatively estimated.
That’s why, also in the simulation model, all values on process time have been considered as
constant (set equal to the In-Process time indicated in the questionnaires for the AS-IS
configuration, and changed accordingly to the proposed modifications in case of TO-BE
configuration). Another reason why process times are taken as constant while waiting times
are modelled through probability distributions is that, while the former are well consolidated
and subject to low variability, since once the activity can be start, the time necessary to
complete it is almost always the same, the latter are out of the direct control of the resources
involved in the process.
Timing definitions and time functions defined for simulation models are shown in Table 13
and 14:
Table 13 Simulation Timings AS-IS
Timed event In-process time (Rework time) or Wait time Function Arena Expression Unit of measure
Project arrival rate 3 projects/year Exponential EXPO(122) days
Info collection 1,75 h (0,25 h) Constant value Tinfocollection(Critic,R) hours
PreSoco preparation 2,5 h (0,25 h) Constant value Tpresocopreparation(Critic, R) hours
Wait for PreSoco Pre-SoCo can be done only on Friday of the week after presentation uploaded Uniform UNIF(7,11) days
PreSoco 0,5 h (0,25h) Constant value Tpresoco(Critic,R) hours
PreSoco validation Between 0 and 3 days Uniform UNIF( 0,3 ) days
VRF preparation 1,5 h Constant Value PBVRF(Critic) hours
VRF designer suppliers preparation 1,5 h Constant Value PBVRF(Critic) hours
Technical specifications + drawing prep. 3h / 5h / 8h Constant Value Tspecifications(Critic) hours
Functional specifications preparation 7h Constant Value Tspecifications(Critic) hours
RFQ 0,5 h Constant value TRFQ(Critic) hours
Wait for offer On average 20 days (10 days) Exponential TwaitO(R) days
Offer collection 1 h (0,5 h) Constant value Toffercollection(R,Critic) hours
Design review 2 h (0,5 h ) / 6 h (1,5 h) / 8h (2 h) Constant value TDR(R,Critic) hours
Wait for technical offer Between 4h and 1w (between 0 and 2 days) Uniform TwaitTO(R) hours
Technical offer collections 2 h (1 h) Constant value TToffercollection(R) hours
Technical Design review 8h (2h) Constant value TtechnicalDR(R) hours
Wait for commercial offer On average 10 days Exponential EXPO(10) days
Commercial offer collection 1 h Constant value Tcoffercollection(1) hours
Negotiation 1 h (1 h) / 3 h (3 h) / 5 h (5 h) / 5 h (5 h) Constant value Tnegotiation(R,Critic) hours
SoCo preparation 2,5 h (0,25 h) / 3 h (0,25 h) / 3,5 h (0,25 h) / 3,5 h (0,25 h) Constant value Tsocopreparation(R,Critic) hours
Wait for SoCo SoCo slot can be book only on Friday of the week after is required Uniform UNIF(7,11) days
SoCo 0,5 h (0,25h) Constant value Tsoco(R,Critic) hours
75
Table 14 Simulation Timings TO-BE
One important attribute which is essential in order to run the simulation has been called
“nproj”: it is initialized to 1, and it is assigned to the first 18 components that enter the
process, then it is increased by 1, and assigned to the following 18 components and so on. This
attribute allows to know, once they are sread throughout the process, to which project each
component belongs to. Once each component comes to the end of the sourcing process, its
“nproj” is checked and, if it is equal to 1 (meaning that it belongs to the first project who
arrived), a variable called “Nprojout” (initialized to 0) is increased by one unit. This allows to
set as terminating condition for the simulation “Nprojout=18”, and getting all the necessary
statistics related to life-cycle of a whole project.
Moreover, with a simple modification (to increase the variable “Nprojout” when both the
conditions on the attributes of the component exiting the process nproj=1 and Critic = 4) it is
possible to collect stastics on the time necessary to complete the sourcing process for
components made by Designer Suppliers (with criticity equal to 4).
In order to run the simulation models, the following replication parameters have been set:
Number of replications: 100;
Warm-up period: 365 days, in order to get stable statistics not subject to initializaion
bias;
Hours per day: 8;
Timed event In-process time (Rework time) or Wait time Function Arena Expression Unit of measure
Project arrival rate 3 projects/year Exponential EXPO(122) days
Info collection 1,75 h (0,25 h) Constant value Tinfocollection(Critic,R) hours
One Page generation 1 h (0,25 h) Constant value TOnePagegeneration(Critic, R) hours
Light PreSoco Between 0,5 and 5 days Uniform UNIF(0,5) days
Wait for PreSoco Pre-SoCo can be done only on Friday of the week after presentation uploaded Uniform UNIF(7,11) days
Standard PreSoCo 0,5 h (0,25h) Constant value Tpresoco(Critic,R) hours
PreSoco validation Between 0 and 3 days Uniform UNIF( 0,3 ) days
VRF preparation 1,5 h Constant Value PBVRF(Critic) hours
VRF designer suppliers preparation 1,5 h Constant Value PBVRF(Critic) hours
Technical specifications + drawing prep. 3h / 5h / 8h Constant Value Tspecifications(Critic) hours
Functional specifications preparation 5h Constant Value Tspecifications(4) hours
RFQ 0,5 h Constant value TRFQ(Critic) hours
Wait for offer On average 15 days (5 days) Exponential TwaitO(R) days
Design review 2 h (0,5 h ) / 6 h (1,5 h) / 8h (2 h) Constant value TDR(R,Critic) hours
Wait for technical offer Between 4h and 1w (between 0 and 2 days) Uniform TwaitTO(R) hours
Technical offer collections 1h (1 h) Constant value TToffercollection(R) hours
Technical Design review 8h (2h) Constant value TtechnicalDR(R) hours
Wait for commercial offer On average 5 days Exponential EXPO(5) days
Negotiation 1 h (1 h) / 3 h (3 h) / 5 h (5 h) / 5 h (5 h) Constant value Tnegotiation(R,Critic) hours
One Page SoCo update 2 h (0,25 h) / 2 h (0,25 h) / 2 h (0,25 h) / 2 h (0,25 h) Constant value Tsocopreparation(R,Critic) hours
Wait for SoCo SoCo slot can be book only on Friday of the week after is required Uniform UNIF(7,11) days
Standard SoCo 0,5 h (0,25h) Constant value Tsoco(R,Critic) hours
Light SoCo Between 0,5 and 5 days Uniform UNIF(0,5) days
76
Terminating condition: Nprojout=18 (or 2, for checking the time necessary to process
components with criticity = 4).
ANNEX V and VI show an overview the Arena models for AS-IS and TO-BE sourcing processes,
while both simulation outputs are going to be detailed and analyzed.
3.4.1 AS-IS process simulation
Regarding AS-IS sourcing process, the time to complete the sourcing process for all the 18
components of one project has been collected for each of the 100 replications: it resulted an
average value of 149.8 days (with a standard deviation of 34.3 days). Moreover, Arena
directly provided the following Output Summary of the 100 replications:
What is interesting to notice is that, in the time to complete the sourcing process for one
project (149.8 days), the System.NumberOut identifier suggests that not only the 18
components of the reference project have been completed, but also 28-18=10 “new”
components belonging to other projects that entered the system later on. Precisely, having a
look to C.NumberOut identifiers, it is possible to deduce how many additional components
completed the process according to their criticity level.
Furthermore, it is finally possible to get an indication of resource utilizations,that is, 41.67%
for R&D and 47.80% for PB. These values, together with the average time to complete the
sourcing process, can be compared to the numbers got from the mathematical model (TPET,
µPB and µR&D), to see to what extent it fits with the simulated process.
77
Math. Model Simulation
TPET [days] 168,2 149,8
TPET [months] 8,4 7,5
PB utilization 46% 47,8%
R&D utilization 42% 41,7%
Why does utilization values given by the mathematical model almost coincide with the
simulation ones, despite the fact of having different TPETs? The possible explanation is that
the lower TPET resulting from simulation is balanced by an almost equal reduction of Total
Process Time, due to the fact that, in the time horizon considered for the simulation, PB and
R&D effectively work on 28 components, while the assumption we made for the mathematical
model is that there are always, on average, 2 projects under sourcing, meaning that in the
TPET resources work on 36 components. Thus, the decrease of both TPET and TPT from
mathematical model imply that the utilization of both resources remains stable: this is a
confirmation that the assumptions made for both models are coherent.
Another important indication that simulations allows to get is the time necessary to complete
the sourcing process for components provided by Designer Suppliers (i.e. the two
components whose criticity level is equal to 4). AS-IS configuration simulation’s results is 75.5
days (3.8 months): if we consider the worst case of having bench tests not successfully passed
(as it often happens), we have to add 3 months of tests in order to validate the design.
Anyways, 3.8 months is not too bad, anyways with the improvements introduction we wish to
achieve on one side a reduction of this time while, on the other side, thanks to the new way of
sharing functional and technical specifications with designer suppliers, the aim is to
consistently cut the probability that long bench tests fail.
3.4.2 TO-BE process simulation
Moving to the TO-BE process, 100 replications give a TPET with average 103.6 days and
standard deviation 32.3 days.
78
Also in this case, during the time to complete a whole sourcing process, also 10 components
belonging to another project have been processed, that means, all what discussed for the AS-
IS process still hold.
As done before, it is possible to get an indication of resource utilizations, that is, 50.6% for
R&D and 40.4% for PB. These values, together with the average time to complete the sourcing
process, can be compared to the numbers got from the mathematical model (TPET, µPB and
µR&D), to see to what extent it fits with the simulated process.
Math. Model Simulation
TPET [days] 139,6 103,6
TPET [months] 7,0 5,2
PB utilization 38% 40.4%
R&D utilization
48% 50.6%
As has been done for the AS-IS configuration, simulations has been run to get the average time
it takes to complete the sourcing process for components provided by Designer suppliers. The
result is 61.7 days (3.1 months), that, if compared to 75.7 days of the AS-IS process, entails a
18.7% reduction. Furthermore, the adoption of the new standard for functional specifications
is estimated to bring consistent drop in terms of bench test failures that, combined with the
overall reduction of time to process critical components, allow to estimate that the design
freeze milestone for such components can be reasonably achieved in approximately 5 months
(with 6 months as worst case, if bench test fail and have to be repeated).
To conclude, it is possible to compare the benefits in terms of Total Process Elapsed Time and
resources utilizations: since the mathematical model is affected by all the limitations that have
79
been previously illustrated, it is clear that, while it behaves “well” in calculating the resources
utilizations (this suggests that the lower TPET resulting from simulation is balanced by an
almost equal reduction, in percentage terms, of Total Process Time, as discussed before), it
will under-estimate the TPET reduction.
days %
ΔTPET Math -27,1 -16,3%
ΔTPET Simulation -46,2 -30,8%
It is possible, then, to calculate a coefficient that allow the “conversion” of the benefits
estimated through the mathematical model in terms of TET reduction (ΔTET(k)) on each
activity affected by process changes, as if they were calculated by simulation. This coefficient,
that we will call d, is then given by:
𝒅 =ΔTPET Simulation
ΔTPET Math=
46.2
27.1= 1.7
Moreover, since we have
∆𝑇𝑃𝐸𝑇 = ∑ ∆𝑇𝐸𝑇 (𝑎𝑐𝑡𝑖𝑣𝑖𝑡𝑖𝑒𝑠 𝑎𝑓𝑓𝑒𝑐𝑡𝑒𝑑 𝑏𝑦 𝑖𝑚𝑝𝑟𝑜𝑣𝑒𝑚𝑒𝑛𝑡𝑠)
(see §X.3.4)
It follows that, for each improved activity, we can calculate with the mathematical model what
we now call ΔTET(k) calc, and then adjust it in order to dampen the effects of all the
associated limitations, obtaining what we define as ΔTET(k) adj :
∆𝑇𝐸𝑇(𝑘)𝑎𝑑𝑗 = ∆𝑇𝐸𝑇(𝑘)𝑐𝑎𝑙𝑐 ∙ 𝑑
Table 15 shows the calculated values ∆𝑇𝐸𝑇(𝑘)𝑎𝑑𝑗 and ∆𝑇𝐸𝑇(𝑘)𝑐𝑎𝑙𝑐 for each of the activities
affected by one of the proposed improvements (Light process, One Page or Technical
specifications form introduction).
80
Table 15 ∆𝑻𝑬𝑻(𝒌)𝒂𝒅𝒋 calculations
3.4.3 Value Added, NVA and waiting times
To conclude with the analysis, another feature of simulation can be exploited: the possibility
to distinguish among Value Added, Non-Value added and waiting time for each component on
each activity of the process.
Arena gives these information for each replication of the simulation (in our specific case,
100); for the sake of simplicity, after having collected all the values from the replications, only
the average values are shown, in order to allow a quick comparison.
First of all, it is necessary to define, for each of the two models, the timing typology associated
to each PROCESS block (by definition, all the DELAY blocks will be classified as “Waiting”
time).
In order to distinguish between Value Added and Non-Value Added times, the information
collected through questionnaires are needed. In particular, for each activity the person
interviewed has been asked to write down the In-process time he dedicates, and also the
Core-process time: the difference between these two values can be interpreted as the NVA
associated to the specific activity. Table 16 shows the conclusions drawn for the AS-IS
process:
Proposed Improvement TET(k) Δ TET(k) calc [days] Δ TET(k) adj [days]
AS-IS 5,7
TO-BE 2,3
AS-IS 29,2
TO-BE 28,7
AS-IS 1,8
TO-BE 1,3
AS-IS 33,7
TO-BE 0,0
AS-IS 4,6
TO-BE 2,3
AS-IS 10,3
TO-BE 0,0
AS-IS 16,6
TO-BE 36,6
AS-IS 10,0
TO-BE 15,0
AS-IS 7,1
TO-BE 4,6
AS-IS 29,3
TO-BE 28,7
146,3
119,2
8,5
-4,3
-0,9
-46,1
-0,9
-0,9
-57,3
-3,8
-17,4
34,0
TOTAL AS-IS (activities affected by changes)-27,1
TOTAL TO-BE (activities affected by changes)
11. SoCo
13. SoCo validationA) Light process -0,5
10. SoCo preparation B) One Page -2,5
9. Negotiation B) One Page 5,0
8a. Design Review B) One Page 20,0
7c. Commercial offers collection B) One Page -10,3
7b. Technical offers collection C) Technical specifications form -2,3
7a. Offers Collection B) One Page -33,7
4b. Functional specifications preparation C) Technical specifications form -0,5
3.Pre-SoCo
12. Pre-SoCo validationA) Light process -0,5
2. Pre-SoCo preparation B) One Page -3,4 -5,7
81
Table 16 Identification of Value added, NVA and waiting time for AS-IS process
One important remark: as far as it concerns Pre-Soco and SoCo, they both have been scored as
Value Added with respect to the parameter “V6- Profitability target satisfaction”, since the
selection of the right suppliers bid list (Pre-SoCo) and the following nomination of the best
supplier in terms of prices is crucial in order to ensure project profitability. That’s why these
two activities cannot be eliminated from the Sourcing process. Anyways, they also scored very
bad in terms of other value indicators, especially on “V4 – Reduce workload/schedule”, in
questionnaires filled by Project Buyers. That’s because the driver of these activities is the
Segment Leader, who checks and, eventually, proposes improvements to the work done by
the Project Buyer; anyways, for standard components, the fact that the Project Buyer must
book a slot, waiting for the meeting and then attend it to rarely get few marginal indications is
perceived as totally NVA. That’s why, being the process improvements objective to reduce the
Project Buyer workload and Total Process Elapsed Time, in the simulation model all the times
dedicated to Pre-SoCo and SoCo activities have been labeled as NVA.
Based on these information, it is possible to run the simulation model and collect information
on average VA, NVA and Waiting times for each component typology. Results are shown in
Table 17:
Timed event In-process time (Rework time) or Wait time Typology
Project arrival rate 3 projects/year -
Info collection 1,75 h (0,25 h) VA
PreSoco preparation 2,5 h (0,25 h) 40% NVA
Wait for PreSoco Pre-SoCo can be done only on Friday of the week after presentation uploaded W
PreSoco 0,5 h (0,25h) NVA
PreSoco validation Between 0 and 3 days W
VRF preparation 1,5 h VA
VRF designer suppliers preparation 1,5 h VA
Technical specifications + drawing prep. 3h / 5h / 8h VA
Functional specifications preparation 7h 30% NVA
RFQ 0,5 h VA
Wait for offer On average 20 days (10 days) W
Offer collection 1 h (0,5 h) 50% NVA
Design review 2 h (0,5 h ) / 6 h (1,5 h) / 8h (2 h) VA
Wait for technical offer Between 4h and 1w (between 0 and 2 days) W
Technical offer collections 2 h (1 h) 50% NVA
Technical Design review 8h (2h) VA
Wait for commercial offer On average 10 days W
Commercial offer collection 1 h 50% NVA
Negotiation 1 h (1 h) / 3 h (3 h) / 5 h (5 h) / 5 h (5 h) VA
SoCo preparation 2,5 h (0,25 h) / 3 h (0,25 h) / 3,5 h (0,25 h) / 3,5 h (0,25 h) 33% NVA
Wait for SoCo SoCo slot can be book only on Friday of the week after is required W
SoCo 0,5 h (0,25h) NVA
82
Table 17 Simulation results in terms of VA, NVA and Waiting times
In order to allow some comparison on these results, it is necessary to use a uniform unit of
measure (i.e. days), then we identify the two following indicators (calculated for each
component typology):
𝑁𝑉𝐴 𝑇𝑖𝑚𝑒
𝑉𝐴 𝑇𝑖𝑚𝑒 : we expect that the values of this indicator in TO-BE configuration are lower
than the ones calculated for the AS-IS, since the proposed improvements aim at
reducing as much as possible all the identified NVA timings;
𝑊𝑎𝑖𝑡 𝑇𝑖𝑚𝑒
𝑇𝑜𝑡𝑎𝑙 𝑇𝑖𝑚𝑒 : indicates the share of total time necessary to complete the Purchasing
process that is due to waiting times.
Calculations results are shown in Table 18:
Table 18 Time performance indicators
As we can notice, the ratio between Waiting Time and Total Time remains almost constant:
this indicates that Total time reduction is almost completely due to waiting times reduction
(this is obvious since the process times – VA or NVA – only account for a marginal part of total
elapsed time). Anyways, the first indicator shows that, in terms of process times, remarkable
decreases of NVA times are achieved thanks to the proposed improvements, and also the total
in process time (VA+NVA) decreases for each component. As expected, the highest effects in
terms of NVA reductions are achieved for standard components (Criticity 1) because they
most benefit from the Light Pre-SoCo/SoCo processes introduction.
Criticity level 1 2 3 4 Criticity level 1 2 3 4
VA Time [h] 11,76 22,96 32,64 35,28 VA Time [h] 11,816 21,6 31,984 35,592
NVA Time [h] 4,48 4,08 4,72 7,28 NVA Time [h] 0,32 0,224 0,736 1,16
Wait Time [days] 85,67 95,08 83,55 65,79 Wait Time [days] 60,27 56,87 59,30 53,61
AS-IS TO-BE
Criticity level 1 2 3 4 Criticity level 1 2 3 4
VA Time 1,47 2,87 4,08 4,41 VA Time 1,48 2,70 4,00 4,45
NVA Time 0,56 0,51 0,59 0,91 NVA Time 0,04 0,03 0,09 0,15
Wait Time 85,67 95,08 83,55 65,79 Wait Time 60,27 56,87 59,30 53,61
Total time 87,70 98,46 88,22 71,11 Total time 61,79 59,60 63,39 58,20
NVA/VA 38,10% 17,77% 14,46% 20,63% NVA/VA 2,71% 1,04% 2,30% 3,26%
Wait Time/Total Time 97,69% 96,57% 94,71% 92,52% Wait Time/Total Time 97,54% 95,42% 93,55% 92,11%
AS-IS TO-BE
83
Conclusions
Throughout this Master Thesis the exploration of how Value Stream Mapping can be applied
to a New Product Development process has been object of study and analysis. The
introduction of a case study process has been helpful in order to show how VSM deals with a
real process, with a focus on the investigation procedure that can be followed in order to
analyze a process, break it down, define and individuate an appropriate set of variables and
performance measures that are necessary in order to spot any possible improvement, and
evaluate the effectiveness of its introduction on the overall process. The results collected
clearly show how VSM is particularly suitable for taking into account and identify the value
embedded inside a NPD process, allowing to identify the improvement areas to work on in
order to reach an higher efficiency in terms of value added and waste reduction. The
methodology elaborated, that is, to put beside VSM, a mathematical model to assess its
performance, and simulation, with the aim to overcome the major limitations of the previous
mathematical model, proved to be very effective in giving a full overview on the process and
the benefits obtained through the proposed improvements. Furthermore, it is important to
remark that this methodology can be easily generalized and adapted to a wide variety of NPD
processes, with a focus on aspects such as value and waste. The application of VSM to the case
study has shown that consistent improvements can be brought to a process, with good results
even without a large data set to start from. Data can be collected through different sources:
this study focused on the people the best know the process itself:, that are, the actors who get
involved in its day-by-day activities. The experience of those people showed to be an
invaluable asset for the identification of everything that is Non-Value Adding inside a process,
thus allowing to bring consistent benefits if exploited properly. In order to do that, resources
have to be aligned in pursuing the same objective, that is, waste identification and elimination,
through the tools (i.e. the structure of the interviews) that have been widely illustrated and
discussed. The identification of possible improvements to the process, and their effectiveness,
are a direct consequence of many factors such as the level of process breakdown achieved and
data on activities process and waiting times: any mistake in in the correct individuation of the
critical path activities inside the process under study would result in useless “improvements”,
meaning that they would maybe positively impact only the resources workloads, but not the
overall completion time.
84
The quantitative assessment of the VSM application effectiveness was the main objective of
this Thesis, and it has been possible through the elaboration of a mathematical model that,
starting from few, simple data collected with the VSM methodology, allowed to calculate two
key process performance indicators: Total Process Elapsed Time (TPET) and resources
utilization factors (µ). The model has been applied on both the AS-IS and TO-BE case study
process configurations, showing that the improvements coming from the application of VSM
and the consequent analysis of results positively impact the process itself on both
performance indicators mentioned above.
Anyways, the model showed some important limitations:
1) It is static: it does not take into account the fact that, while the process for components
of a new project is on-hold, new projects can start, or maybe there are still components
belonging to older projects still in the process.
2) The model does not take into account that, once a new NPD project starts the process,
the various sub-components that have to be processed are “spread” among the
activities, depending on process times and probabilities of rework. The model, instead,
sees the sub-components as a “block” that moves from one activity to the next one as it
was a single entity: this makes the Elapsed Time be over-estimated and, as a
consequence of that, also the TPET results inflated.
3) Priorities and time to complete the sourcing process for critical components cannot be
neither modeled nor detected by the formulas previously introduced;
4) The model is deterministic: all time values are approximated with the simple mean.
The use of simulation allowed to overcome the abovementioned limitations. The comparison
of the results shows that the utilization values given by the mathematical model almost
coincide with the simulation ones, while significative differences are registered in terms of
Total Process Elapsed Times (TPET given by the model is higher than the value got from
simulation). This suggests that the lower TPET resulting from simulation is balanced by an
almost equal reduction (in % terms) of Total Process Time, due to the fact that, in the time
horizon considered for the simulation, the resources effectively work on a lower number of
components (as indicated by simulation outputs) with respect to the assumption made for the
mathematical model, due to the fact that it considers the projects as a “block” of sub-
components. In addition to that, also the introduction of stochasticity of process times plays a
major role. Thus, the decrease of both TPET and TPT from mathematical model imply that the
85
utilization of both resources remains stable: this is a confirmation that the assumptions made
for both models are coherent.
The use of simulation allowed to easily make some additional considerations in terms of the
impact of proposed improvements on process Value-Added and Waiting times: the ratio
between Waiting Time and Total Time remains almost constant, indicating that Total time
reduction is almost completely due to waiting times reduction (this is obvious since the
process times – VA or NVA – only account for a marginal part of total elapsed time). Anyways,
remarkable decreases of NVA times are achieved thanks to the proposed improvements, and
also the total in process time (VA+NVA) decreases for each component.
As a conclusion, this study can be easily replicated in order to assess the performance and to
improve a large family of NPD processes, with a methodology that combines the more
qualitative tools of VSM with the quantitative performance assessment coming from the
introduction of a mathematical model and simulation. All the model limitations that have been
highlighted open to the possibility of making further improvements, such as different ways of
model refinement in order to make it more “sophisticated” in detecting key aspects of the
process that, in our case, required the introduction of simulation, such as, time stochasticity.
Furthermore, the study relies on data and information collected though a rather “qualitative”
way, that is, relying on the experience of the resources involved in the process. Of course, the
more refined the way of collecting data, the better the output obtained: different, more
scientific methods to obtain the various process timings could be adopted and effectively
integrated, depending on the process under. Another feature that could be added to the model
is the possibility to discriminate between Value-Added and NVA times, that is something that,
again, has been done exclusively with simulation. A further, interesting extension of this
study could be the exploration of new, alternative ways to effectively integrate VSM with the
planning techniques that have only been mentioned for the literature review. In other words,
additional studies could be made in order to explore how the methodology introduced can
effectively interact with and give support to the branch of highly effective process planning
techniques and tools, such as Gantt, PERT, CPM), that are widely adopted by most of the
companies today.
86
Bibliography
McManus et al., Lean Engineering: Doing the Right thing Right, Massachusetts Institute
of Technology, 2005;
Womack J.P., Jones D.T., Lean Thinking: Banish Waste and Create Wealth in Your
Corporation, Simon & Schuster, New York, 1996;
AA.VV, Enterprise Value Stream Mapping and Analysis, Lean Aerospace Initiative, MIT,
2003;
Rother M., Shook J., Learning to see: Value Stream Mapping to add value and eliminate
MUDA, Spi edition;
Cantamessa M., Cobos E., Rafele C., Il Project Management. Un approccio sistemico alla
gestione dei progetti, ISEDI, 2000.
Chase, James P., Value creation in the product development process, Massachusetts
Institute of Technology, 2001;
87
ANNEXES
ANNEX I: One Page Template (Pre-SoCo and SoCo)
88
ANNEX II: Functional specification form
Project Réf. Doc. Creation date Revision date Copy
Product Type
Dual Mass Flyw heel Curve
Functionalities
Implantation - Implantation Request
Contact areas with the spring:
Flat Wire Technology:
Mechanical
1. TEST N°1:
Temperature:
Grease
Speed:
Frequency 2: Sinusoidal signal
Number of cycles (frequency 1):
2. TEST TMAX
Grease
Sinusoidal signal
Number of cycles
Tenue en Température - Temperature
Extreme temperatures
Tenue Physico-Chimique - Chemical
Quality Requirements
Reliability
Quality
PPM from assembly lines
Customer quality incidents
Banned or Regulated Substances
Without material neither treatment prohibited by rules
General Requirements
To be defined
Particular Request
Delivery : direct to plan - daily
To give technical solutions x
To draw and dimension the part x
36 Hz with an amplitude of ±1°
6x356 cycles
80°C
The part must resist to: gasoline, diesel; synthetic brake and clutch liquid, antifreeze
mixture, engine oil, battery electrolyte, grease, protection oil, machining fluid, saline fog
Continuous operation
TEST N°2 CRITERIA
K x maximum engine torque (torque reached in 20s) (K depends on the application
(indicative value: 5))
1.1 PHASE 1: ENDURANCE DUAL FREQUENCY (see graph bellow)
120°C
-30 to +220°C
between –2.2xCm and 5 x Cm
with a frequency of 1 Hz.
No rupture
No slackening
Springs
Frequency 1: Triangular signal 1.5 Hz between
1.06xCm and –0.25xCm
MANDATORY FOR THIS APPLICATION
1.50 Hz between 1.06xCm
and –0.25xCm
ØD = 29,0 mm
ØRmoy = 122,3 mm
ØR (=[ØRmoy + ØD/2])= 175,3 mm (±6)
A (free angle) = 126,3° (±0,75°)
To transmit torque from the primary flywheel to the secondary flywheel.
80°C
Supplied by the company
3500 RPM
Temperature:
Supplied by the company
0
0.6 ppm
Safety, Regulation, identification, recycling,
appearance, handling, storage, packaging
Ensure that there is no shifting between the coils in use and
extra torque (10 x engine torque )
Remote transmission of delivery schedules (EDI)
The tests described above are used in Valeo they can be
reproduced exactly or adapted on the specific test tools of the supplier
80000 cycles
Engine torque : 715Nm
Nom Torque of the DMF : 1160 Nm
(including tolerances and 1.8 SF)
Min Torque of the DMF : 971 Nm
(including tolerances and 2.2 SF)
The stiffness/torque curve must be below
the enclosed curve
Total mass of springs: to be minimize
Mini Torque for 1 Curve Spring Set: 426
Nm
To damp torque oscillation transmitted from the primary flywheel to the secondary flywheel
No pre-load
There are 3 Curved Springs Set. Springs are working in parallel.
B10 - 300000 km
PART FUNCTIONAL SPECIFICATION
Performances criteria and Level
Performances criteria and LevelFunctional Requirements
Technical Requirements Performances criteria and Level
Required tests Performances criteria and Level
Created by
Part
89
Act
ivit
y ID
k
Act
ivit
y n
ame
R
Cri
tici
ty (
z)p
t(k,
z) [
h]
PT(
k) [
h]
RT(
k) [
h]
TP
T(k)
[h
]m
ax w
t(k,
z) [
d]
ET(k
) [d
]r(
k,z)
rt(k
,z)
[h]
max
rw
t(k,
z) [
d]
RET
(k)
[d]
TET(
k) [
d]
lST
ET(i
) [
d]
11
,75
00
21
,75
0,1
0,2
53
1,7
50
,20
,25
41
,75
0,3
50
,25
12
,50
02
2,5
0,1
0,2
53
2,5
0,2
0,2
54
2,5
0,3
50
,25
10
,50
02
0,5
0,1
0,2
53
0,5
0,2
0,2
54
0,5
0,3
50
,25
1-
--
-0
-2
--
--
0,1
-3
--
--
0,2
-4
--
--
0,3
5-
13
--
25
--
38
--
4-
--
--
--
--
1-
-2
--
-3
--
-4
71
40
14
01
,8-
-0
01
1,5
--
21
,5-
-3
1,5
--
41
,5-
-1
0,5
--
20
,5-
-3
0,5
--
40
,5-
-1
11
0,5
21
20
,53
12
0,5
4-
--
1-
--
--
--
--
-2
--
--
--
--
--
3-
--
--
--
--
-4
24
61
0,0
3,0
3,5
31
1,0
1,1
1-
--
2-
--
3-
--
41
20
21
01
0,3
--
--
12
10
,52
62
1,5
38
22
4-
--
--
--
--
-1
--
--
--
--
--
2-
--
--
--
--
-3
--
--
--
--
--
48
16
12
28
02
,03
20
1,5
1-
1-
2-
2-
3-
2-
4-
3-
11
0,0
51
23
0,1
33
50
,35
54
50
,45
51
2,5
0,0
50
,25
23
0,1
0,2
53
3,5
0,3
50
,25
43
,50
,45
0,2
51
0,5
0,0
50
,25
20
,50
,10
,25
30
,50
,35
0,2
54
0,5
0,4
50
,25
1-
--
-0
,05
-2
--
--
0,1
-3
--
--
0,3
5-
4-
--
-0
,45
-
3,0
0,0
0,0
11
,0
3,0 0 - 0,0
0,0
10
,0 - 0 - 0,0
0,0
11
,0
3,0
5,6
12
,1
3,0
1In
fo c
oll
ect
ion
& S
up
pli
er
pre
se
lect
ion
PB
31
,50
,63
2,1
0,1
0,0
Re
wo
rk t
ime
s
3,9
1
3P
re-S
oco
P
B9
0,6
9,6
2P
re-S
oco
pre
par
atio
nP
B4
50
,64
5,6
2 3
91
09
1
4bFu
nct
ion
al s
pe
cifi
cati
on
s p
rep
arat
ion
R&
D-
-
12P
re-S
oco
VA
LID
ATE
D ?
SL
4aTe
chn
ical
sp
eci
fica
tio
ns
+ d
raw
ings
pre
par
atio
nR
&D
-
4 5 6
6R
FQP
B9
09
,0
5V
RF
pre
par
atio
nP
B7 8
0
7bTe
chn
ical
off
ers
co
lle
ctio
nR
&D
7cC
om
me
rcia
l off
ers
co
lle
ctio
nP
B
7aO
ffe
rs c
oll
ect
ion
PB
9 10
11
15
16
8bTe
chn
ical
de
sign
re
vie
wR
&D
14P
reli
min
ar d
esi
gn v
alid
ate
d ?
R&
D
8aD
esi
gn r
evi
ew
R&
D1
2
13
14
0,1 11
3,0- -
2,3
5,3
-
10
,0
7,1
13So
co V
ALI
DA
TED
?SL
11So
Co
PB
3,0
- -
- 0 -
10So
Co
pre
par
atio
nP
B5
61
,05
7
9N
ego
tiat
ion
PB
62
18
,28
0,2
0
- 1,1
22
,02
9,5
0,0
11
,0
3,0 0 - 0,0
0,0
20
,0
11
,4
27
3,4
-
91
10
90
42
,51
32
,51
1,3- - 7
,8
7,0
12
,1
- -
-
0,0
0,0
11
,0
4,6
10
,3
16
,6
3,5 -
23
,3
6,0
1,1
33
,7
4,6
10
,3
16
,6
3,5
16
4,0
5,7
23
,2
6,0
1 1 2
1,1
33
,71
3,5
4,0
5,7
23
,2
6,0
11
,4
1,8
3,4
0 12
0,1
11
,1
3,0 0
17
18
10
,0
7,1
23
,3
6,0
13
,1
1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
-
27
ANNEX III : Application of the mathematical model to the AS-IS process
90
Act
ivit
y ID
k
Act
ivit
y n
ame
R
Cri
tici
ty (
z)p
t(k,
z) [
h]
PT(
k) [
h]
RT(
k) [
h]
TP
T(k)
[h
]m
ax w
t(k,
z) [
d]
ET(k
) [d
]r(
k,z)
rt(k
,z)
[h]
max
rw
t(k,
z) [
d]
RET
(k)
[d]
TET(
k) [
d]
lST
ET(i
) [
d]
11
,75
00
21
,75
0,1
0,2
53
1,7
50
,20
,25
41
,75
0,3
50
,25
11
00
21
0,1
0,2
53
10
,20
,25
41
0,3
50
,25
10
,50
02
0,5
0,1
0,2
53
0,5
0,2
0,2
54
0,5
0,3
50
,25
1-
--
-0
-2
--
--
0,1
-3
--
--
0,2
-4
--
--
0,3
5-
1-
--
--
-2
--
--
--
3-
--
--
-4
--
--
--
13
--
25
--
38
--
4-
--
--
--
-1
--
--
--
-2
--
--
--
--
3-
--
--
--
-4
51
00
10
0,0
1,3
--
11
,5-
-2
1,5
--
31
,5-
-4
1,5
--
10
,5-
-2
0,5
--
30
,5-
-4
0,5
--
1-
--
--
--
--
-2
--
--
--
--
--
3-
--
--
--
--
-4
12
68
,01
,51
,83
10
,50
,61
21
0,5
26
21
,53
82
24
--
--
--
--
--
1-
--
--
--
--
-2
--
--
--
--
--
3-
--
--
--
--
-4
81
61
22
80
2,0
32
01
,51
--
--
--
1-
2-
--
--
-2
-3
--
--
--
2-
4-
--
--
-3
-1
10
,05
12
30
,13
35
0,3
55
45
0,4
55
12
0,0
50
,25
22
0,1
0,2
53
20
,35
0,2
54
20
,45
0,2
51
0,5
0,0
50
,25
20
,50
,10
,25
30
,50
,35
0,2
54
0,5
0,4
50
,25
1-
--
-0
,05
-2
--
--
0,1
-3
--
--
0,3
5-
4-
--
-0
,45
-1
--
--
0,0
5-
2-
--
-0
,1-
3-
--
-0
,35
-4
--
--
0,4
5-
5,0
0,0
11
,0
5,0
3,0
5,0
11
,0
3,0 0 0,0
0,0
15
,0
Re
wo
rk t
ime
s
1In
fo c
olle
ctio
n &
Su
pp
lier
pre
sel
ecti
on
PB
31
,50
,63
2,1
0,0
0,0
3,9
2,3
0,1
0,1
10 0
3St
and
ard
Pre
-So
co
PB
50
,65
,6
2"O
ne
Pag
e" g
ener
atio
nP
B1
80
,61
8,6
2 3
91
09
1
12
Pre
-So
co V
ALI
DA
TED
?SL
3i
Ligh
t P
re-S
oco
SL
4 5
4b
Fun
ctio
nal
sp
ecif
icat
ion
s p
rep
arat
ion
R&
D
5V
RF
pre
par
atio
nP
B
4a
Tech
nic
al s
pec
ific
atio
ns
+ d
raw
ings
pre
par
atio
nR
&D
6 7
27
02
7,0
6R
FQP
B9
09
,0
8 9
90
42
,51
32
,5
8b
Tech
nic
al d
esig
n r
evie
wR
&D
7Te
chn
ical
off
ers
colle
ctio
nR
&D
8a
Des
ign
rev
iew
R&
D
10
11
12
11
,1 3
13
Soco
VA
LID
ATE
D ?
SL
11
Stan
dar
d S
oC
oP
B5
0,9
Ligh
t So
co
16
17
18
11
iSL
14
Pre
limin
ar d
esig
n v
alid
ated
?R
&D
9N
ego
tiat
ion
PB
13
14
0 0 0 0
2,3
36
,6
3,5 -
0 -
4,0
2,3
22
,7
6,0
5,0
11
,4
1,3
3,4
1,1
11
,6
3,0 5
11
,4
3,4
1,1
26
,3
0 0 0 0 511 3 0
6
62
18
,28
0,2
10
On
e P
age
SoC
o u
pd
ate
PB
36
1,0
37
,01
5
12
,8
4,5
11
,6
5,0
3,0
10
,3
3
2,3
- 0 0 11 5
0,1
-
15
,0
4,6
1 2
6,0
11
,1 5 3
22
,7
10
,0
6,0
22
,7
15
,0
4,6
1 1 1 1 1 1 1
4,0
2,3
1 1 2 1 1 2
1,1
28
,7
12
,6
1 1 1
2,3
36
,6
3,5
ANNEX IV : Application of the mathematical model to the TO-BE process
91
ANNEX V : Arena model for AS-IS process
ANNEX VI : Arena model for TO-BE process