*Corresponding author. Tel.:#31-40-247-2390; fax: #31-40-246-7497.
E-mail address:[email protected] (A.C. Brombacher).
Abstract
An overview is given of the role companies, and their business processes, have in product quality during the product lifecycle of a product. The basic business processes and possible organisation forms of those processes are discussed. The trends in these business processes are used to illustrate the current inherent instability of these processes. It is explained
how companies can deal with this instability using paradigms from control theory where the quality information#ow in
a company is used to analyse and optimise product quality. An example illustrates the presented methods. Finally
conclusions and future lines of research are given. ( 2000 Elsevier Science B.V. All rights reserved.
Keywords: Product quality; Product lifecycle; Product creation process; Feed-forward; Feedback
1. Introduction
Customers expect to get products with an extensive functionality and a high reliability for a reasonable price. The challenge for industry in a competitive world-wide market is to develop these products in a fraction of the time and cost compared with 10 years ago. This puts a high pressure on the business processes that generate these products. Solutions that are applied in order to meet with these challenges are: concentration on core business, strategic alliances, outsourcing and co-operation.
Co-operation implies exchange of information. This means that the participants in the product creation process must know not only their own task, but also the tasks of the other parties in the process. These tasks can be deduced from the struc-ture of the product creation process. It must be well known who needs what information and why. Information connects the di!erent processes. Prod-uct quality related information is generated during actual use in the"eld, in tools, methods, and tests in the primary business processes and in sub-pro-cesses of the primary business prosub-pro-cesses. The information that is generated will#ow through the organisation. More about the role of information #ows in product creation can be found in [1,2]. [1] presents the Maturity Index on Reliability and [2] discusses the special contribution of Service Centres to quality improvement.
Fig. 2. Phases in the product lifecycle.
Fig. 1. Transformation of customer requirements into a product.
In this paper the basic structure of the product creation process is given, and the standard termin-ology is explained. In Section 2 we give the phases of the product lifecycle. In Section 3 we describe the functions that together make up the realisation process. The basics of the organisation of the pri-mary business processes are presented in Section 4. Section 5 describes how current trends in these business processes lead to inherent instability. Sec-tions 6 and 7 describe how to analyse and optimise product quality in an unstable business process using quality information #ows. Section 8 illus-trates how the analysis and control of these quality information #ows can be used in a practical example. Finally Section 9 presents the conclusions and future lines of research.
2. The product lifecycle
The goal of product creation is transforming customer requirements into a product that satis"es the customer needs (Fig. 1).
The process of transforming product-related cus-tomer requirements into a product that ful"ls these requirements can be subdivided into phases. These phases will be referred to as the product lifecycle phases (Fig. 2):
f speci"cation phase: transformation of customer requirements into speci"cations of the future product function;
f design phase: transformation of speci"cations into a detailed technical speci"cation of the fu-ture product function (the design);
f manufacturing phase: realisation of the design into a physical product;
f customer use phase: actual use of the product by the end-user.
3. Realisation processes
The process in a company that delivers products to the market within the given organisational struc-tures and organisation's goals will be referred to as the realisation process (Fig. 3).
Fig. 3. The realisation process.
Fig. 4. The realisation process can be divided into primary and secondary business processes.
marketing, development, production, sales and service (Fig. 4).
The primary business processes will be discussed here brie#y.
f Research: The development of new technologies. f Marketing: Understanding and identifying the
market need.
f Development: De"nition and design of the prod-uct and the prodprod-uction capacity.
Parts of the development process are: (pre) con-cept generation and selection; system, sub-systems and piece/parts design; production capacity design.
Fig. 5. Business processes consist of many sub-processes.
Fig. 7. Concurrent organisation of business processes. Fig. 6. Sequential organisation of business processes.
Parts of the production process are: the assembly process; the production of sub-systems and piece/parts.
f Sales: In#uencing the market need.
f Service: When the product cannot ful"l the cus-tomer expectation, the service system will take care of a proper treatment of the customer's complaint.
Note that the business processes consist of many sub-processes (Fig. 5).
E.g. the development process can be divided into:
f product development
f C system development f C } concept development f C } concept selection f C sub-system development f C piece/part development
f process development
f C system f C sub-system f C piece/parts (tools)
4. Trends in the structure of the primary business processes
In this section the basic structures of the primary process are presented. It regards sequential and concurrent processes, technology/knowledge streams and sub-contracting.
4.1. Sequential processes
The traditional approach to organising the busi-ness processes is a sequential one. In a sequential approach tasks are performed one after another. Upstream tasks are completed before downstream tasks are started (Fig. 6). The sequential approach is often referred to an the`throw it over the walla
approach. It almost always coincides with strongly functionally organised organisations.
4.2. Concurrent processes
Since approximately 1980 concurrent processes in the"eld of engineering have received much at-tention. The idea behind concurrent processes is that downstream activities start as early as possible, even when upstream activities have not yet been completed (Fig. 7). The classic example is: start the development of the production capacity together with the development of the product (concurrency of two activities in the development process). An-other example could be: start the production even before the design is completed. This example may sound exotic for mass-produced products, but less for e.g. buildings, etc. (although piece/parts and sub-systems developed and produced today can be used in tomorrow's design of a car). Of course some activities will always have to be completed before others can start, but on a macrolevel activities are performed concurrently.
Fig. 8. Knowledge streams outside of any speci"c development project.
performed in close co-operation with the project team. Concurrent processes and working in teams have several advantages above the sequential ap-proach. These advantages are well described in [4]. Other literature describes di!erent levels of information transfer. [5] discerns"ve levels in the degree of concurrence between upstream and downstream activities (increasing concurrency from 1 to 5):
1. the traditional sequential approach; 2. high-bandwidth technology transfer;
3. overlapping with preliminary information trans-fer;
4. overlapping with mutual adjustment;
5. overlapping with early downstream development.
4.3. Technology/knowledge stream
New technologies are the foundation for new products. [4] argues for the development of tech-nologies outside of any speci"c product program. A technology stream can represent technology development. Mature (robust) and speci"c develop-ment programs (Fig. 8) "sh out superior techno-logy. Development of new technology can be done on the level of sub-systems, sub-functions (e.g. noise, vibration) or on a collection of sub-systems. One could even argue in favour of the creation of
development streams that create ready to imple-ment sub-systems (in fact this is the case when piece/parts or sub-systems are picked out of a cata-logue). Another expansion could be the creation of other streams e.g. a market development stream.
4.4. Sub-contracting
Both the primary and secondary processes can be sub-contracted by the company in part or as a whole. Sub-contracting means that some of the activities in the realisation process are performed by third parties (Fig. 9). In the case of the primary processes development and production the sub-contractors are often called suppliers.
Supplier involvement has been subject of study in the past years. [5] discerns three di!erent pat-terns:
1. supplier proprietary parts: development and production at supplier;
2. black box parts: development split between assembler and supplier;
3. detail-controlled parts: development at the assembler and production at the supplier.
Fig. 9. Sub-contracting of business processes.
Fig. 10. Five levels of con#icts with the customer requirements [8].
put the suppliers in the multifunctional project team or to consider the supplier as a technology stream from which the project team can pick ma-ture and ready to use technology or sub-systems (cf. [6]).
5. Trends in product quality
The success a company has in ful"lling the cus-tomer requirements can be expressed by the term
quality. A broad de"nition of quality is therefore: conformance to requirements. These requirements include many aspects of di!erent nature including objective as well as subjective aspects and aspects relating to time, price, etc. (see [7] for an overview of the many available de"nitions of quality).
The subset of quality that is relevant in this paper will be de"ned as product quality: conformance to product-related customer requirements. The prod-uct is a manufactured prodprod-uct. The customer is the end-user during actual use of the product in the "eld. The customer requirements are the requirements that should be ful"lled to satisfy the customer need. In this paper only product-related requirements are of interest. This means that as-pects like delivery time, price, etc. are not included. Taking the de"nition of customer requirements in the broadest sense means that if a product does not have su$cient satis"ers for the customer this already leads to non-quality. Often a more narrow de"nition of customer requirements is used. A good working representation of the di!erent interpreta-tion levels of what can be meant by customer
requirements is given in Fig. 10, where customer requirements are interpreted in"ve di!erent ways.
5.1. Trends in product quality
According to [8] as far as warranty is concerned, the trend in the "eld of quality and reliability is towards the more extended de"nitions of product quality (Fig. 11).
In this paper customer requirements will be interpreted as customer expectations. This leads to the following de"nition of product quality: con-formance to customer expectations. Note that this de"nition includes the less extended de"nitions as well. The more extended de"nition of product qual-ity, in which the de"nition of requirements is extended to customer satis"ers, is a "eld of study for marketing. Some are in favour of de"ning this as the product function [8]. Product function is then de"ned as one of four business drivers: cost, time, quality and function. Product quality is about mak-ing the product right while product function is about making the right product.
Not performing according to customer expecta-tions will have an impact on the ful"lment of the company's objectives. Important business drivers like cost, time and market share will be in#uenced by the realised product quality. Many books have been written about the cost aspects of quality. A classi"cation of quality costs has been made by Juran into prevention costs, appraisal costs, inter-nal failure costs and exterinter-nal failure costs (cf. [9]):
Fig. 11. Warranty trends in the"eld of quality and reliability are towards the more extended de"nitions.
Fig. 12. Classical, sequential, development process.
f appraisal costs: include measuring, evaluating, or auditing products and processes to assure con-formance to quality standards and percon-formance requirements;
f internal failure costs: all costs that arise from products not meeting the speci"cations before they are delivered to the customer;
f external failure costs: all costs that arise from products not meeting the speci" cations/expecta-tions after they have been delivered to the cus-tomer.
Non-quality can cause serious time delays, espe-cially when problems arise late in the creation pro-cess. It will often take much time to implement the changes, and projects can be delayed severely due to quality problems. Moreover, poor quality can lead to loss of market share on the long term. People will no longer buy products of a particular company if they have had been experiences with the products realised by that company.
Note that since the product is the output of a realisation process consisting of many unstable processes and sub-processes, product quality is dif-"cult to predict. It will be di$cult to know in advance whether the product will satisfy the end-user expectations or not.
5.2. Product optimisation in classical,sequential or functional,development processes
The classical way to solve unpredictability in a development process is to apply so-called
functional or Taylor organisation structures. This functional structure leads to a situation that the development of a product is split in a number of di!erent tasks that are then considered to be inde-pendent (Fig. 12). From an uncertainty point of view this has certain advantages. During a develop-ment phase a product is being adapted until it is able to achieve its functionality; during the (pre-) production phase people focus on production aspects until a product is mature on production aspects.
Fig. 13. Concurrent engineering process; large distance between decision and validation.
The disadvantage, from an engineering point of view, is that the phases will never be truly indepen-dent. Decisions taken in the development process can seriously a!ect the way a product is produced or the way the customer perceives the product. Also from an economic point of view there are disadvan-tages. Stevens [10] stated that 80% of the cost structure (and therefore the pro"tability) of a prod-uct is determined in the early phases of prodprod-uct development. Also iterations in the later phases of the development process will, due to the larger amount of information or even physical structures involved that are a!ected, be far more expensive and far more time consuming. Therefore, it might be useful to take decisions that relate to later phases of a development process already in the early phases. As there is no longer a strict focus of one activity per phase it enables to carry out activities in parallel.
5.3. Inherent instability of modern development processes
Due to the resulting concurrency of activities this process is also referred to as`concurrent engineer-inga. Advantages are a faster and more economic time to market (due to the more e$cient back-end process). Disadvantages are long distances (in time but also often in the people) between decisions and the e!ect of the decisions (Fig. 13). This requires a very high predictability of risks. In a static situ-ation where all aspects of a development (products, technology and people) remain the same such a prediction could, theoretically, be possible. In a situation with a high degree of uncertainty on one of these aspects, processes will have a tendency to become unstable. In very short development pro-cesses it might happen that even before the e!ects of new technology are known already a next genera-tion technology is introduced. In short develop-ment processes with long learning cycles, people will focus on the current product instead of on the lessons learned from one or two product generations ago. This will lead, without proper precautions, to inherent instability of the business process.
6. How to manage unstable processes
The output of the transformation processes dis-cussed in the previous section can often not be predicted. When transformation processes are con-sidered as open loop processes they will never be stable and therefore not predictable. This means important aspects like time, costs and quality are not always under control. Many tools and methods have been developed to control these processes, especially for the aspects time and costs. In this section some general approaches towards unstable processes will be discussed. Since this paper is con-cerned with product quality the examples will be product quality related. Note that the approaches described in this section can be applied to processes as well as sub-processes of these processes.
6.1. Inspection of the output
Inspection of the output means that the actual output is compared to the planned output. If the output is not according to plan, the output will be rejected (Fig. 14). Note that inspection of the out-put will not contribute to stabilising the process.
Some examples of inspection of the output are the following:
f realisation process: inspection of the product just before the product is delivered to the market; f primary processes: inspection at the end of
primary processes e.g. development process, production process;
Fig. 15. Adapt the subsequent process to the output of the previous process.
machines.
6.2. Local feed-forward
In the case of local feed-forward the subsequent process is forced to deal with the output of the previous process. Two solutions are possible: adapt the subsequent process or adjust the subsequent process parameters. By adapting the process is meant improving the process by improving the process capabilities. Note that improving the capa-bility of a process will not make the process stable. Undesired outputs can be produced with advanced methods as well as with less advanced methods. In the case of adjusting the process parameters the process itself does not change, but the process is shifted to another target.
f check the output and adapt the subsequent pro-cess (Fig. 15);
f check the output and adjust the parameters of the subsequent process (Fig. 16).
Examples of local feed-forward:
f realisation process: the customer has to adapt to the product;
f primary processes: identify the customer needs and throw the results over the wall to develop-ment;
f sub-processes: design the product and throw it over the wall to engineering;
f sub-sub processes: process parameter adjust-ment in production processes.
6.3. Local feedback
In the case of local feedback the output from the subsequent process is used to adapt the previous process or to adapt the input of the previous process.
f check the output and adapt the process (Fig. 17); f check the output and adjust process parameters
(Fig. 18).
From control theory one can learn that unstable models require feedback. Verifying the outputs, feedback and adjusting the inputs will lead to con-trolled processes.
Examples of local feedback:
f realisation process: use information of cus-tomer's experiences with the product while deter-mining customer requirement for new products; f primary processes: use information of the pro-duction process in the development process of new products;
Fig. 17. Improve the process through feedback of the process output.
Fig. 18. Change the process parameters through feedback of the process output.
Fig. 19. Anticipate subsequent processes and verify the results: global optimisation.
6.4. Global optimisation
Global optimisation can be reached by anticipa-ting in the current process the subsequent process and verifying the results (Fig. 19).
Anticipation is only possible if enough know-ledge of the subsequent processes is available. Models are needed of the subsequent processes and veri"cation of the results is necessary to keep these models up to date.
Examples of global optimisation:
f realisation process: anticipate in the whole realisation process the customer requirements and the customer user environment;
f primary processes: anticipate in the development process the requirements and constrains of the production process;
f sub-processes: anticipate during product engin-eering the possibilities of production process engineering;
f sub-sub processes: use a model of the customer requirements and the environment in tools, methods and tests.
In relation to the earlier sections this leads to the conclusion that a modern, time-driven, concurrent engineering process requires a highly e$cient feed-forward and feedback system. The quality of the information should be such that (causes of) devi-ations are found fast and are embedded in the models or `knowledge basea with a high level of accuracy and e$ciency.
7. Product quality related information6ows
Information plays an important role in the realisation process. First of all it connects the di! er-ent processes. The di!erent processes that realise the product cannot work independently. Informa-tion transfer between the processes is crucial. The output of upstream processes serves as input for downstream processes.
Fig. 20. Primary process of a company: the product development process.
In order to evaluate the quality of these control loops Brombacher has proposed and applied the MIR concept in many actual cases. The MIR scale uses four levels to assess the quality of information in control loops. On this four level scale MIR level 1 indicates adequate measurements, MIR level 2 in-dicates adequate allocation of (causes of) deviations in the process, MIR level 3 indicates that informa-tion has su$cient level of detail to"nd root-causes. Finally, MIR level 4 indicates that the information is adequate to install preventive measures. See also [11,12].
In summary, it can be concluded that several kinds of reliability information#ows exist, informa-tion#ows on process level up to the level of activities or methods and tests and information #ows that measure, react or improve the realisation process.
8. Product quality and quality of information6ows, an example
Fig. 20 gives the primary process of a large com-pany, active in the area of high-volume consumer
and Sales. A key-account manager is responsible for every group of customers. He builds relation-ships with the customers and picks up and dis-cusses the customer's wishes.
f Development: The de"nition and design of prod-ucts, sub-systems and piece/parts. For the devel-opment of a product a project team is composed which works concurrently on several tasks of the development process.
f Production: The actual realisation of products, sub-systems and key components. The manufac-turing of sub-systems and piece/parts takes place at approximately 50 suppliers spread over the whole world.
f Sales: Sales is done in the Marketing & Sales department. The same people perform the mar-keting tasks as well as the sales tasks. The focus of the sales department is on convincing the customers to buy end-products. However, there is no clear distinction between those two pro-cesses.
Fig. 21. Involvement of departments in business processes.
Fig. 22. Quality information#ows.
managers (see marketing). If problems occur with the product in the "eld at the customer, service takes care of a proper treatment of the customer's complaints and eventually of repair or replacement.
Four major departments can be distinguished in which the primary business functions are performed. These departments are the Innovation department, the Marketing & Sales department, Purchasing and the Production department. The primary business functions are divided over the four major departments in a way that is represented in Fig. 21.
In order to analyse the quality information#ows in this company an analysis has been made of the various sources of quality-related information and the way this information is deployed throughout the business process. Fig. 22 gives a mapping of the quality information sources and the quality-related activities in this company.
In Fig. 22 several quality information#ows can be determined:
f Customer quality support: Main goal of this activ-ity is monitoring of the outgoing product qualactiv-ity, both in terms of line rejects (products failing during the production process) and"eld failures. In case of deviations a problem analysis team is installed (`Red-alert procedurea).
f Problem analysis team: In case of`out of control situationsaon either production quality or"eld quality a problem analysis team is installed. In this team people from various disciplines partici-pate. After the cause of the problem has been found and the problem has been eliminated the PAT is dissolved. The results of PAR activities are not structurally used for other (existing or future) products.
Using the MIR concept it is in this way possible to model the adaptive capabilities of a business pro-cess. From the example, presented here, a number of conclusions can be drawn:
In this case quality information#ows are mainly feedback structures and are mainly department oriented. However, the time requirements on time-driven processes like this would at least require a combination of (cross-functional) feed-forward and feedback.
Analysis beyond MIR level 1 is only started in case of `red-alertsa and the analysis is strongly reactive. Learning beyond the level of a single prod-uct development cycle, in this case, does not exist. This implies that knowledge, other than via the personal experience of people, is not preserved well in this organisation and that cross-functional co-operation an predicative capabilities are not developed well.
9. Conclusions and future lines of research
Modern, time-driven, product development pro-cesses require fast learning capabilities. In order to reach the market in a shorter period of time many companies have adopted concurrent engineering strategies. In spite of these concurrent engineering the time constants of learning cycles have become longer due to the fact that the period between (early) decision and validation of the decision has become longer. This requires that decisions, taken early in the product development process, are taken based on highly accurate and detailed information #ows operating with short reaction times. Only this enables a combination of forward and feed-back control that is needed for successful concur-rent engineering.
implies that, with the existing structure, it will be almost impossible to operate a modern, pro-active, concurrent engineering process in this company.
References
[1] P.C. Sander, A.C. Brombacher, MIR: The use of Reliabil-ity Information Flows as a maturReliabil-ity index for qualReliabil-ity management, Quality and Reliability Engineering Interna-tional 15 (1999).
[2] V.T. Petkova, P.C. Sander, A.C. Brombacher, The use of quality metrics in service centres, International Journal of Production Economics 67 (1) (2000), 27}36.
[3] M. Weggeman, G. Wijnen, R. Kor, Ondernemen binnen de Onderneming: Essenties van Organisaties (Enterprising within an Enterprise, Essentials of Enterprises, in Dutch), Kluwer, Deventer, 1997.
[4] D. Clausing, Total Quality Development: A Step-by-Step Guide to World-class Concurrent Engineering, ASME Press, New York, 1994.
[5] K.B. Clark, T. Fujimoto, Product Development Perfor-mance: Strategy, Organisation and Management in the World Auto Industry, Harvard Business School Press, Boston, MA, 1991.
[6] L. Dijkstra, C.W.G.M. Dirne, C.P.M. Govers, P.C. Sander, Samenwerking in Ontwikkeling (Co-operation in Devel-opment, in Dutch), Kluwer, Deventer, 1997.
[7] D.A. Garvin, Managing Quality, Free Press, New York, 1988.
[8] A.C. Brombacher, Symposium`The Reliability Challengea organised by Finn Jensen Consultancy, London, 1998. [9] A. Diallo, Z.U. Khan, CMA, C.F. Vail, Cost of quality, in:
The New Manufacturing Environment, Management Accounting, August 1995, p. 20.
[10] F. Stevens, Vele eersten zullen de laatsten zijn (in Dutch), Frits Philips Institute for Quality Management, Eindhoven, The Netherlands, 1993.
[11] A.C. Brombacher, MIR: Covering non-technical aspects of IEC61508 reliability certi"cation, Reliability Engineering and System Safety 66 (1999) 109}121.
![Fig. 10. Five levels of con#icts with the customer requirements[8].](https://thumb-ap.123doks.com/thumbv2/123dok/3115961.1378522/6.544.33.241.49.181/fig-levels-icts-customer-requirements.webp)
