Editor | On 11, Feb 2004

By: Pierluigi Petrali

Abstract
A structured workflow for an integrated product/process optimization is presented. This workflow is intended mainly for cost-reducing objectives and is based on an integrated usage of different methodologies along with TRIZ.

Introduction
It’s well known that TRIZ is a powerful way to address and to solve difficult technical problem, but, due to several causes we won’t address in this article, its successful introduction to day by day activities in product development seems still to be demonstrated. The same seems to be happened to other methodologies, such as various Design for X, QFD, and so on. The reasons for this partial success are to be investigated, but perhaps one of the main reason is related to complexity.

When dealing with complex technical systems, i.e. systems delivering more than one function, or composed of many different subsystems or very large number of components, the need for a complete set of tools, methodologies and skills arise. Another important aspect is the strong link existing between product and process: the more a product is mature, having a long lifecycle, high capital invested in production, and the more the process will be influencing product features. So for industries facing this reality, it’s important to design a process of product optimization in which:

1. The process is taken into account
2. T he methodologies helping product conceptualization are used maximizing their potential
3. The point of observation could be easily zoomed and de-zoomed from microscopic to macroscopic

Background
Many works have evidenced in the past the synergetic power of using TRIZ as complement to Quality Function Deployment, Six Sigma, Design for Manufacture and Assembly, Axiomatic Design, Taguchi etc. Unfortunately, system/product complexity makes these approaches very difficult to apply in a structured and scalable way, and whereas for well defined and confined problem or objectives, methodology synergy offer great advantages to users, for others, undefined, fuzzy and more generic ones, they just help some phases of the work. We could call this approach, bottom-up: using a combination of methodologies to address micro-problems or well defined objectives.

On the other hand, companies need to innovate in order to achieve competitive advantages, and they need to have tools with a different perspective, more strategic than tactical, in order to decide where, when, what and how to innovate, for example to decide whether it would be better to make incremental or radical innovation on a technology. Both of the approaches, bottom-up (providing powerful ways to combine tools to solve micro-problems: i.e. tactical approach) and top -down (or providing the indication on what-when-how to innovate a product) need to be combined. Smith [1] offered a new and more completed view on these subjects. His work is an attempt to locate each methodology in a two-dimensions array, one related to Suh’s domains of design, and the other related to reality perception according to Senge’s Systemic Thinking. The highest level of perception, according to Senge, is Systemic Thinking, that allow to formulate structural explanation to reality, while the lowest are Event Thinking, and, Pattern Thinking

This framework demonstrates its usefulness in understanding methodologies potentiality and in providing orientation in methodologies world, and served as a basement to design or re-engineering process.

Mixing skills and methodologies.
Having in mind the complete framework proposed by Smith [1] one question arises: are all the methodologies necessary ? At which level of knowledge? Of course companies can’t afford to have people in their development department completely trained in all the methodologies, so it’s important to design a development process in which we can identify a well-specified path, and the methodologies useful at each step.

The observed approach in companies is to specialize people in just one methodology. So, at the end, they have some experts with a deeply knowledge in their specific field, but, very often without any structure to connect them and to make them work together.

One drawback of this approach is that the expert is focused on maximizing the outcomes from applying its methodology forgetting the potential of using other tools. The second drawback is that experts tend to develop specific communication protocols among their community, so the communication between different methodologies can be very difficult if not impossible.

For companies aiming to develop a structured way of working using synergy of methodologies, is crucial to plan with accuracy people education on different methodologies, and to focus on mixing experts in team building.

Product/process optimization: a structured approach
Mature product and technologies, for which the S-curve is in the decline stage, are very often under big pressure of competition, and therefore cost-reduction is one of the main drivers in product/process optimization. This cost reduction, once achieved, can be used mainly in three ways: improving margins, or improving market share by decreasing prices, or improving product Value by adding new functions or by improving the existing ones. From this point of view cost-reduction projects, can be considered as strategic projects, since they could lead to three different strategies for the same product.

Product cost is always a sum of different factors, starting from design to outbound logistic. Large part of this cost is represented by material cost and production cost. For major domestic appliances, as well for cars, the quote of production costs derived from manual assembly operations can be quite big, as explained in figure 2: up to 15% of product cost can be represented by labor cost.

Historically the most common approach to face cost-reduction is to make parallel and disjoined efforts, so, for example, Procurement Division is asked to reduce material cost, Production and Logistic divisions are asked to optimize their processes in order to reduce Labor and Overhead costs, Product Development is asked to re-design product using less material or cheaper component. But, since all the cost chain is depending from Product, it’s clear that the biggest influence on final cost is in Product itself. In other words the product need to be intrinsically cost-reducing.

When all the efforts to optimize each single piece of the chain reach their limit, incremental-based innovation are no longer effective, and a most structured and methodology -driven action is to be taken. Our method of re-engineering, we named InnoproductTM, is based on adopting different methodologies, is oriented to a general perception of the cost-chain and is focused on product/process design. Its general workflow is presented in figure 3

InnoproductTM workflow, made up on the background of Suh’s domains of design process, was designed for exceptional activities, since it address product re-engineering, and not new product development.
The roadmap is based on models and vectors of transformation of models,

· P is Product Model
· F is Functional Model
· PR is Process Model
· P’ is Product Model Evolved
· F’ is Functional Model Evolved
· PR’ is Process Model Evolved

Working on models, although difficult and requiring high level of abstraction, give some advantages:
1) models are representations of the reality shared among team members: it’s a way to reduce subjective perception against objective one.
2) models can be represented graphically so to capture tacit knowledge and share it through the company
3) models can be transformed using only brain energy

Each transformation from one model to another is guided by specific use of methodology, each phase will be briefly explained:

Starting point
The starting point of the roadmap is selection of product to be optimized and relative process, and soon bifurcate, left for product-driven path of optimization, right for process optimization.

Ending point
The ending point is a new process, in fact InnoproductTM can be seen as a way to make architectural process innovation .

Product-driven innovation branch
This branch is the most important and the longest. The main scope is to capture product function, to
create a model of it, to transform this model according to the objectives, to re-create a physical model
for it and to find out the optimal processes to produce it.

PþF transformation
The scope of this transformation is to make functional model of the entire product. Design for Assembly, used in tear-down mode and Value Engineering and Analysis are used to make precise Function Models. Value Analysis is preferred at this stage since it covers cost issues and customer perspective.

For complex systems a Functional Subsystems tree can be created: dealing with many simple functional model is better than working on few very complicated. Moreover, considerations of Value Analysis made at different levels along the tree can help in determine priorities in next steps.

FþF’ transformation
This is the most important conceptual stage: DFMA guidelines and, moreover, TRIZ, are used to draw new architectures for existing product. Customer Domain Check-up

In all previous transformation the Customer Domain (the Voice of Customer) was not involved directly. This check-up is absolutely required to validate new functional model against customer attributes, so to be sure that no useful functions for the customer have been eliminated, reduced or dramatically changed.

F’þP’ transformation
New architectural model is to be re-transformed in a physical model; that is, concepts are to be transferred into solution. TRIZ, DFMA guidelines, Modularity are used to design the new physical model.

P’þPr’ transformation
New process for new product has to be defined and designed. Process-driven innovation branch

Along this branch the present process is to be redesigned, both a macro and a micro-level. Using TRIZ we can act a micro-level to solve process problem causing cost increase, process time increase, stock increase and so on. At macro level TRIZ laws of evolution can help in understand process evolution limits.

The Role of TRIZ in Whirlpool InnoproductTM approach
As explained in previous section, almost all the stages of an InnoproductTM process use TRIZ as predominant methodology. However TRIZ can be seen at different levels of perception and usage. In FþF’ transformation, TRIZ has a strategic and tactic role [2] : laws of evolutions can be used, along with a technological maturity assessment, to determine a general direction of evolution and to differentiate lines of evolution for product subsystems. Of course, this transformation of functional model (which can consist for example in function redistribution among preserved component in an intensive system simplification) can generate several technical problem to be solved using traditional tools: ARIZ, Su -Field, Principles and Contradiction Matrix.

Also TRIZ plays a fundamental role in shaping team members minds: some abstract concepts like IFR (Ideal Final Results), the recognition (and the removal) of psychological barriers, the role of Supersystems as resources, after some months of immersion in TRIZ workshops and seminars, can pervade and permeate each individual and group mental activity related to address a technical problem.

Observations
We have already identified some possible improvement for InnoproductTM :
· System complexity and multiple project objectives need some other tools to help decision making at early stage, when functional model is to be transformed. One possible solution for dealing with product complexity, or better with range complexity is to work with a modular approach, that is to identify modules and interfaces in your system so that your whole product range can be derived from combination of several basic modules. The earlier you can apply a modular approach to your system, the better you can evaluate its benefit.
· Some other methodologies need to be embedded in the process.

On the other hand, the approach has demonstrated good robustness in being scaled up and down according to different project dimension and objectives, provided that the matter be product optimization or re-engineering