Value analysis, function analysis & FAST are methods for improving a product's value proposition.

VALUE ANALYSIS AND
FUNCTION ANALYSIS SYSTEM TECHNIQUE

Adapted by Kenneth Crow
DRM Associates

2002 DRM Associates  All rights reserved. May be used with attribution. Other use prohibited.

Product Development Forum
NPD Body of Knowledge
Design-to-Cost Paper
Target Costing
Value Analysis Workshop
DRM Associates

THE CONCEPT OF VALUE

The value of a product will be interpreted in different ways by different customers. Its common characteristic is a high level of performance, capability, emotional appeal, style, etc. relative to its cost. This can also be expressed as maximizing the function of a product relative to its cost:

Value = (Performance + Capability)/Cost = Function/Cost

Value is not a matter of minimizing cost. In some cases the value of a product can be increased by increasing its function (performance or capability) and cost as long as the added function increases more than its added cost. The concept of functional worth can be important. Functional worth is the lowest cost to provide a given function. However, there are less tangible "selling" functions involved in a product to make it of value to a customer.

INTRODUCTION TO VALUE ANALYSIS

Lawrence Miles conceived of Value Analysis (VA) in the 1945 based on the application of function analysis to the component parts of a product. Component cost reduction was an effective and popular way to improve "value" when direct labor and material cost determined the success of a product. The value analysis technique supported cost reduction activities by relating the cost of components to their function contributions.

Value analysis defines a "basic function" as anything that makes the product work or sell. A function that is defined as "basic" cannot change. Secondary functions, also called "supporting functions", described the manner in which the basic function(s) were implemented. Secondary functions could be modified or eliminated to reduce product cost.

As VA progressed to larger and more complex products and systems, emphasis shifted to "upstream" product development activities where VA can be more effectively applied to a product before it reaches the production phase. However, as products have become more complex and sophisticated, the technique needed to be adapted to the "systems" approach that is involved in many products today. As a result, value analysis evolved into the "Function Analysis System Technique" (FAST) which is discussed later.

THE VALUE ANALYSIS METHOD

In all problem solving techniques, we are trying to change a condition by means of a solution that is unique and relevant. If we describe in detail what we are trying to accomplish, we tend to describe a solution and miss the opportunity to engage in divergent thinking about other alternatives. When trying to describe problems that affect us, we become locked in to a course of action without realizing it, because of our own bias. Conversely, the more abstractly we can define the function of what we are trying to accomplish, the more opportunities we will have for divergent thinking.

This high level of abstraction can be achieved by describing what is to be accomplished with a verb and a noun. In this discipline, the verb answers the question, "What is to be done?" or, "What is it to do?" The verb defines the required action. The noun answers the question, "What is it being done to?" The noun tells what is acted upon. Identifying the function by a verb-noun is not as simple a matter as it appears.

Identifying the function in the broadest possible terms provides the greatest potential for divergent thinking because it gives the greatest freedom for creatively developing alternatives. A function should be identified as to what is to be accomplished by a solution and not how it is to be accomplished. How the function is identified determines the scope, or range of solutions that can be considered.

That functions designated as "basic" represent the operative function of the item or product and must be maintained and protected. Determining the basic function of single components can be relatively simple. By definition then, functions designated as "basic" will not change, but the way those functions are implemented is open to innovative speculation.

As important as the basic function is to the success of any product, the cost to perform that function is inversely proportional to its importance. This is not an absolute rule, but rather an observation of the consumer products market. Few people purchase consumer products based on performance or the lowest cost of basic functions alone. When purchasing a product it is assumed that the basic function is operative. The customer's attention is then directed to those visible secondary support functions, or product features, which determine the worth of the product. From a product design point of view, products that are perceived to have high value first address the basic function's performance and stress the achievement of all of the performance attributes. Once the basic functions are satisfied, the designer's then address the secondary functions necessary to attract customers. Secondary functions are incorporated in the product as features to support and enhance the basic function and help sell the product. The elimination of secondary functions that are not very important to the customer will reduce product cost and increase value without detracting from the worth of the product.

The cost contribution of the basic function does not, by itself, establish the value of the product. Few products are sold on the basis of their basic function alone. If this were so, the market for "no name" brands would be more popular than it is today. Although the cost contribution of the basic function is relatively small, its loss will cause the loss of the market value of the product.

One objective of value analysis or function analysis, to improve value by reducing the cost-function relationship of a product, is achieved by eliminating or combining as many secondary functions as possible.

VALUE ANALYSIS PROCESS

The first step in the value analysis process is to define the problem and its scope. Once this is done, the functions of the product and its items are derived. These functions are classified into "basic" and "secondary" functions. A Cost Function Matrix or Value Analysis Matrix is prepared to identify the cost of providing each function by associating the function with a mechanism or component part of a product. Product functions with a high cost-function ratio are identified as opportunities for further investigation and improvement. Improvement opportunities are then brainstormed, analyzed, and selected.

The objective of the Function Cost Matrix approach is to draw the attention of the analysts away from the cost of components and focus their attention on the cost contribution of the functions. The Function Cost Matrix displays the components of the product, and the cost of those components, along the left vertical side of the graph. The top horizontal legend contains the functions performed by those components. Each component is then examined to determine how many functions that component performs, and the cost contributions of those functions.

Detailed cost estimates become more important following function analysis, when evaluating value improvement proposals. The total cost and percent contribution of the functions of the item under study will guide the team, or analyst, in selecting which functions to select for value improvement analysis.

A variation of the Function-Cost Matrix is the Value Analysis Matrix. This matrix was derived from the Quality Function Deployment (QFD) methodology. It is more powerful in two ways. First, it associates functions back to customer needs or requirements. In doing this, it carries forward an importance rating to associate with these functions based on the original customer needs or requirements. Functions are then related to mechanisms, the same as with the Function-Cost Matrix. Mechanisms are related to functions as either strongly, moderately or weakly supporting the given function. This relationship is noted with the standard QFD relationship symbols. The associated weighting factor is multiplied by customer or function importance and each columns value is added.

These totals are normalized to calculate each mechanism's relative weight in satisfying the designated functions. This is where the second difference with the Function-Cost Matrix arises. This mechanism weight can then be used as the basis to allocate the overall item or product cost. The mechanism target costs can be compared with the actual or estimated costs to see where costs are out of line with the value of that mechanism as derived from customer requirements and function analysis.

FUNCTION ANALYSIS SYSTEM TECHNIQUE

Function Analysis System Technique is an evolution of the value analysis process created by Charles Bytheway. FAST permits people with different technical backgrounds to effectively communicate and resolve issues that require multi-disciplined considerations. FAST builds upon VA by linking the simply expressed, verb-noun functions to describe complex systems.

FAST is not an end product or result, but rather a beginning. It describes the item or system under study and causes the team to think through the functions that the item or system performs, forming the basis for a wide variety of subsequent approaches and analysis techniques. FAST contributes significantly to perhaps the most important phase of value engineering: function analysis. FAST is a creative stimulus to explore innovative avenues for performing functions.

The FAST diagram or model is an excellent communications vehicle. Using the verb-noun rules in function analysis creates a common language, crossing all disciplines and technologies. It allows multi-disciplined team members to contribute equally and communicate with one another while addressing the problem objectively without bias or preconceived conclusions. With FAST, there are no right or wrong model or result. The problem should be structured until the product development team members are satisfied that the real problem is identified. After agreeing on the problem statement, the single most important output of the multi-disciplined team engaged in developing a FAST model is consensus. Since the team has been charged with the responsibility of resolving the assigned problem, it is their interpretation of the FAST model that reflects the problem statement that's important. The team members must discuss and reconfigure the FAST model until consensus is reached and all participating team members are satisfied that their concerns are expressed in the model. Once consensus has been achieved, the FAST model is complete and the team can move on to the next creative phase.

FAST differs from value analysis in the use of intuitive logic to determine and test function dependencies and the graphical display of the system in a function dependency diagram or model. Another major difference is in analyzing a system as a complete unit, rather than analyzing the components of a system. When studying systems it becomes apparent that functions do not operate in a random or independent fashion. A system exists because functions form dependency links with other functions, just as components form a dependency link with other components to make the system work. The importance of the FAST approach is that it graphically displays function dependencies and creates a process to study function links while exploring options to develop improved systems.

There are normally two types of FAST diagrams, the technical FAST diagram and the customer FAST diagram. A technical FAST diagram is used to understand the technical aspects of a specific portion of a total product. A customer FAST diagram focuses on the aspects of a product that the customer cares about and does not delve into the technicalities, mechanics or physics of the product. A customer FAST diagram is usually applied to a total product.

CREATING A FAST MODEL

The FAST model has a horizontal directional orientation described as the HOW-WHY dimension. This dimension is described in this manner because HOW and WHY questions are asked to structure the logic of the system's functions. Starting with a function, we ask HOW that function is performed to develop a more specific approach. This line of questioning and thinking is read from left to right. To abstract the problem to a higher level, we ask WHY is that function performed. This line of logic is read from right to left.

There is essential logic associated with the FAST HOW-WHY directional orientation. First, when undertaking any task it is best to start with the goals of the task, then explore methods to achieve the goals. When addressing any function on the FAST model with the question WHY, the function to its left expresses the goal of that function. The question HOW, is answered by the function on the right, and is a method to perform that function being addressed. A systems diagram starts at the beginning of the system and ends with its goal. A FAST model, reading from left to right, starts with the goal, and ends at the beginning of the "system" that will achieve that goal.

Second, changing a function on the HOW-WHY path affects all of the functions to the right of that function. This is a domino effect that only goes one way, from left to right. Starting with any place on the FAST model, if a function is changed the goals are still valid (functions to the left), but the method to accomplish that function, and all other functions on the right, are affected.

Finally, building the model in the HOW direction, or function justification, will focus the team's attention on each function element of the model. Whereas, reversing the FAST model and building it in its system orientation will cause the team to leap over individual functions and focus on the system, leaving function "gaps" in the system. A good rule to remember in constructing a FAST Model is to build in the HOW direction and test the logic in the WHY direction.

The vertical orientation of the FAST model is described as the WHEN direction. This is not part of the intuitive logic process, but it supplements intuitive thinking. WHEN is not a time orientation, but indicates cause and effect.

Scope lines represent the boundaries of the study and are shown as two vertical lines on the FAST model. The scope lines bound the "scope of the study", or that aspect of the problem with which the study team is concerned. The left scope line determines the basic function(s) of the study. The basic functions will always be the first function(s) to the immediate right of the left scope line. The right scope line identifies the beginning of the study and separates the input function(s) from the scope of the study.

The objective or goal of the study is called the "Highest Order Function", located to the left of the basic function(s) and outside of the left scope line. Any function to the left of another function is a "higher order function". Functions to the right and outside of the right scope line represent the input side that "turn on" or initiate the subject under study and are known as lowest order functions. Any function to the right of another function is a "lower order" function and represents a method selected to carry out the function being addressed.

Those function(s) to the immediate right of the left scope line represent the purpose or mission of the product or process under study and are called Basic Function(s). Once determined, the basic function will not change. If the basic function fails, the product or process will lose its market value.

All functions to the right of the basic function(s) portray the conceptual approach selected to satisfy the basic function. The concept describes the method being considered, or elected, to achieve the basic function(s). The concept can represent either the current conditions (as is) or proposed approach (to be). As a general rule, it is best to create a "to be" rather than an "as is" FAST Model, even if the assignment is to improve an existing product. This approach will give the product development team members an opportunity to compare the "ideal" to the "current" and help resolve how to implement the differences. Working from an "as is" model will restrict the team's attention to incremental improvement opportunities. An "as is" model is useful for tracing the symptoms of a problem to its root cause, and exploring ways to resolve the problem, because of the dependent relationship of functions that form the FAST model.

Any function on the HOW-WHY logic path is a logic path function. If the functions along the WHY direction lead into the basic function(s), than they are located on the major logic path. If the WHY path does not lead directly to the basic function, it is a minor logic path. Changing a function on the major logic path will alter or destroy the way the basic function is performed. Changing a function on a minor logic path will disturb an independent (supporting) function that enhances the basic function. Supporting functions are usually secondary and exist to achieve the performance levels specified in the objectives or specifications of the basic functions or because a particular approach was chosen to implement the basic function(s).

Independent functions describe an enhancement or control of a function located on the logic path. They do not depend on another function or method selected to perform that function. Independent functions are located above the logic path function(s), and are considered secondary, with respect to the scope, nature, level of the problem, and its logic path. An example of a FAST Diagram for a pencil is shown below.

FAST Diagram Example

Adapted from an example developed by J. Jerry Kaufman

The next step in the process is to dimension the FAST model or to associate information to its functions. FAST dimensions include, but are not limited to: responsibility, budgets, allocated target costs, estimated costs, actual costs, subsystem groupings, placing inspection and test points, manufacturing processes, positioning design reviews, and others. There are many ways to dimension a FAST model. The two popular ways are called Clustering Functions and the Sensitivity Matrix.

Clustering functions involves drawing boundaries with dotted lines around groups of functions to configure sub-systems. Clustering functions is a good way to illustrate cost reduction targets and assign design-to-cost targets to new design concepts. For cost reduction, a team would develop an "as is" product FAST model, cluster the functions into subsystems, allocate product cost by clustered functions, and assign target costs. During the process of creating the model, customer sensitivity functions can be identified as well as opportunities for significant cost improvements in design and production.

Following the completion of the model, the subsystems can be divided among product development teams assigned to achieve the target cost reductions. The teams can then select cost sensitive sub-systems and expand them by moving that segment of the model to a lower level of abstraction. This exposes the detail components of that assembly and their function/cost contributions.

INTEGRATING QFD WITH FAST

A powerful analysis method is created when FAST is used in conjunction with QFD. QFD enables the uses of the Value Analysis Matrix. An example of a value analysis matrix for the pencil example is shown below.

Value Analysis Matrix

The steps for using these two methodologies are as follows:

  1. Capture customer requirements and perform QFD product planning with the product planning matrix. Translate customer needs into directly into verb-noun functions or use a second matrix to translate technical characteristics into verb-noun functions.
  2. Prepare a FAST diagram and develop the product concept in conjunction with the QFD concept selection matrix. Review the verb-noun functions in the QFD matrix and assure that they are included in the FAST diagram. Revise verb-noun function descriptions if necessary to assure consistency between the QFD matrix and the FAST diagram.
  3. Dimension the system in the FAST diagram into subsystems/assemblies/parts. These are generically referred to as mechanisms.
  4. Develop value analysis matrix at system level. The "what's" or system requirements/function in the value analysis matrix are derived from either a customer (vs. technical) FAST diagram or by selecting those function statements that correspond to the customer needs or technical characteristics in the product planning matrix. The importance rating is derived from the product planning matrix as well.
  5. Complete the value analysis matrix by relating the mechanisms to the customer requirements/functions and calculate the associated weight. Summarize the column weights and normalize to create mechanism weights. Allocate the target cost based on the mechanism weights. This represents the value to the customer based on the customer importance. Compare with either estimated costs based on the product concept or actual costs if available.
  6. Identify high cost to value mechanisms / subsystems by comparing the mechanism target costs to the mechanism estimated/actual costs

A product or system such as an automobile contains a great many components and would result in an extremely complex FAST model. The complexity of the process is not governed by the number of components in a product, but the level of abstraction selected to perform the analysis. With an automobile, a high level of abstraction could contain the major subsystems as the components under study, such as: the power train, chassis, electrical system, passenger compartment, etc. The result of the FAST model and supporting cost analysis might then focus the team's attention on the power train for further analysis. Moving to a lower level of abstraction, the power train could then be divided into its components (engine, transmission, drive shaft, etc.) for a more detailed analysis.

In other words, the concept of decomposition is applied to a FAST model. The initial FAST model will stay at a high level of abstraction. Starting at a higher level of abstraction allows for uncluttered macro analysis of the overall problem until those key functions can be found, isolated, and the key issues identified. If a function is identified for further study, we note that with a "^" below the function box. A supporting FAST diagram is then created for that subsystem function. This process of decomposition or moving to lower levels of abstraction could be carried down several levels if appropriate.

Once high cost to value mechanisms are identified in the initial system value analysis matrix, the next step is to focus more attention on those mechanisms and associated functions. Dimensioning groups the functions together into those associated with a particular subsystem, assembly or part. The FAST diagram can be expanded into a lower level of abstraction in the area under investigation. The steps involved are as follows:

  1. Use QFD to translate higher-level customer needs to subsystem technical characteristics.
  2. Create FAST diagram at lower level of abstraction for targeted mechanism/subsystem.
  3. Prepare a FAST diagram & develop the product concept in conjunction with the QFD concept selection matrix
  4. Dimension the system in the FAST diagram into assemblies/parts or identify the assemblies/parts needed to perform the given function.
  5. Develop value analysis matrix at a lower level of abstraction for the targeted subsystem. The "what's" or system requirements/function in the value analysis matrix are derived from either a customer (vs. technical) FAST diagram or by selecting those function statements that correspond to the customer needs or technical characteristics in the subsystem planning matrix.
  6. Complete the value analysis matrix and identify high cost to value mechanisms by comparing the mechanism target costs to the mechanism estimated/actual costs
VALUE IMPROVEMENT PROCESS

Performing value analysis or producing the FAST model and analyzing functions with the value analysis matrix are only the first steps in the process. The real work begins with brainstorming, developing and analyzing potential improvements in the product. These subsequent steps are supported by:

  • The QFD Concept Selection Matrix is a powerful tool to evaluate various concept and design alternatives based on a set of weighted criteria that ultimately tie back to customer needs.
  • Benchmarking competitors and other similar products helps to see new ways functions can be performed and breaks down some of the not-invented-here paradigms.
  • Product cost and life cycle cost models support the estimating of cost for the Function-Cost and Value Analysis Matrices and aid in the evaluation of various product concepts.
  • Technology evaluation is leads us to new ways that basic functions can be performed in a better or less costly way. Concept development should involve people with a knowledge of new technology development and an open mind to identify how this technology might relate to product functions that need to be performed. Methods such as the theory of inventive problem solving or TRIZ are useful in this regard.
  • Design for Manufacturability/Assembly principles provide guidance on how to better design components and assemblies that are more manufacturable and, as a result, are lower in cost.

Value Analysis or Function Analysis provide the methods to identify the problem and to begin to define the functions that need to be performed. As we proceed in developing a FAST model, implicit in this process is developing a concept of operation for the product which is represented by all of the lower order functions in a FAST diagram.

Concept alternatives will be developed through brainstorming, benchmarking other products performing similar functions, and surveying and applying new technology. Since multiple concepts need to be evaluated, we want to use a higher level of abstraction for the FAST model to provide us with the greatest flexibility and a minimum level of effort. Trade studies and technical analysis will be performed to evaluate various product concepts. A concept selection matrix is a good tool to summarize a variety of different data and support making a decision about the preferred concept.

All of these steps may be iterative as a preferred concept evolves and gets more fully developed. In addition, there should be a thorough evaluation of whether all functions are needed or if there is a different way of accomplishing a function as the concept is developed to a lower level of abstraction. When a Function Cost or Value Analysis Matrix is prepared, functions that are out of balance with their worth are identified, further challenging the team to explore different approaches.

SUMMARY

Value analysis and its more robust cousin, Function Analysis System Technique, are important analysis tools. These methodologies lead to improved product designs and lower costs by:

  • Providing a method of communication within a product development team and achieving team consensus
  • Facilitating flexibility in thinking and exploring multiple concepts
  • Focusing on essential functions to fulfill product requirements
  • Identifying high cost functions to explore improvements
ABOUT THE AUTHOR

Kenneth A. Crow is President of DRM Associates, a management consulting and education firm focusing on integrated product development practices. He is a distinguished speaker and recognized expert in the field of integrated product development. He has over twenty years of experience consulting with major companies internationally in aerospace, capital equipment, defense, high technology, medical equipment, and transportation industries. He has provided guidance to executive management in formulating a integrated product development program and reengineering the development process as well as assisted product development teams applying IPD to specific development projects.

He has written papers, contributed to books, and given many presentations and seminars for professional associations, conferences, and manufacturing clients on integrated product development, design for manufacturability, design to cost, product development teams, QFD, and team building. Among many professional affiliations, he is past President and currently on the Board of the Society of Concurrent Engineering and is a member of the Product Development Management Association and the Engineering Management Society. For further information, contact the author at DRM Associates, 2613 Via Olivera, Palos Verdes, CA 90274, telephone (310) 377-5569, fax (310) 377-1315, or email at kcrow@aol.com.