Design Reviews and their Impacts on the Enterprise Life Cycle

Table of contents

Design Reviews and their Impacts on the Enterprise Life Cycle

Declaration

Acknowledgements

Abstract

Table of contents

List of Abbreviations

List of Figures

List of Tables

CHAPTER 1: Introduction of the Thesis
1.1 Introduction
1.2 Objectives
1.3 Structure

CHAPTER 2: Design Review - A Key Design Control Element
2.1 Introduction
2.2 What is Design Review?
2.2.1 DO and CO and the need for DR
2.2.2 Definitions of Design Review
2.2.3 Purpose of Design Reviews
2.2.4 Design Review Teams
2.2.5 Conducting DR
2.2.6 Number of DR
2.2.7 Checklists as a tool in DR
2.3 The Product- and the Enterprise Life Cycle
2.3.1 Introduction
2.3.2 Product Life Cycle
2.3.3 Enterprise Life Cycle
2.3.4 Involvement of PLC and ELC

CHAPTER 3: Design Reviews in PLC and ELC
3.1 Introduction
3.2 Design Reviews in PLC
3.2.1 Project Initialisation Meeting
3.2.2 System Requirements Review
3.2.3 System Design Review
3.2.4 Preliminary Design Review
3.2.5 Critical Design Review
3.2.6 Production Readiness Review
3.2.7 Product Strategy Review
3.3 Design Reviews in ELC
3.3.1 Project Initialisation Meeting
3.3.2 System Requirements Review
3.3.3 System Design Review
3.3.4 Preliminary Design Review
3.3.5 Critical Design Review
3.3.6 Commission Review
3.3.7 Operational Review
3.3.8 Disposal Review

CHAPTER 4: Impacts of Design Review
4.1 Introduction
4.2 Intra Phase Impact
4.3 Intra Product Life Cycle Impact or Inter Phase Impact
4.4 Inter Product Life Cycle Impact
4.5 Intra Enterprise Life Cycle Impact

CHAPTER 5: Impacts of product-related DR on the entire Enterprise
5.1 Introduction
5.2 Effects of PIM of PLC on the ELC
5.2.1 Concept Phase
5.2.2 Definition Phase
5.2.3 Design Phase
5.2.4 Construction Phase
5.2.5 Operation Phase
5.2.6 Disposal Phase
5.3 Effects of SRR of PLC on the ELC
5.3.1 Concept Phase
5.3.2 Definition Phase
5.3.3 Design Phase
5.3.4 Construction Phase
5.3.5 Operation Phase
5.3.6 Disposal Phase
5.4 Effects of SDR of PLC on the ELC
5.4.1 Concept Phase
5.4.2 Definition Phase
5.4.3 Design Phase
5.4.4 Construction Phase
5.4.5 Operation Phase
5.4.6 Disposal Phase
5.5 Effects of PDR of PLC on the ELC
5.5.1 Concept Phase
5.5.2 Definition Phase
5.5.3 Design Phase
5.5.4 Construction Phase
5.5.5 Operation Phase
5.5.6 Disposal Phase
5.6 Effects of CDR of PLC on the ELC
5.6.1 Concept Phase
5.6.2 Definition Phase
5.6.3 Design Phase
5.6.4 Construction Phase
5.6.5 Operation Phase
5.6.6 Disposal Phase
5.7 Effects of PRR of PLC on the ELC
5.7.1 Concept Phase
5.7.2 Definition Phase
5.7.3 Design Phase
5.7.4 Construction Phase
5.7.5 Operation Phase
5.7.6 Disposal Phase
5.8 Effects of PSR of PLC on the ELC
5.8.1 Concept Phase
5.8.2 Definition Phase
5.8.3 Design Phase
5.8.4 Construction Phase
5.8.5 Operation Phase
5.8.6 Disposal Phase

CHAPTER 6: Summary of the Thesis
6.1 Conclusions
6.2 Limitations
6.3 Perspectives and Recommendations for Future Research

CHAPTER 7: References

CHAPTER 8: Appendices
Appendix A: Business Principles Definitions
Appendix B: PLC-ELC-Matrix

List of Abbreviations

illustration not visible in this excerpt

List of Figures

Figure 1-1 Customer-Product-Enterprise Relations

Figure 1-2 Structure of the Thesis

Figure 2-1 Distinction between Design- and Control Objectives

Figure 2-2 The Design Process

Figure 2-3 Example of a Checklist in EDENTM /EDEN03c/

Figure 2-4 The Product Life Cycle

Figure 2-5 The Enterprise Life Cycle

Figure 2-6 The PLC builds a Part of the ELC /FISC03/

Figure 3-1 Design Reviews in the Product Life Cycle

Figure 3-2 Design Reviews in the Enterprise Life Cycle

Figure 4-1 Areas of Influence of DR conducted in the PLC of Product A

Figure 4-2 Different Impacts of DR conducted in a PLC within the Enterprise

Figure 5-1 Structure of the PLC-ELC-Matrix

List of Tables

Table 2-1 Design Review Team Member /KAPU92/

Declaration

I, the undersigned, hereby declare that the work contained in this thesis is my own original work and has not previously in its entirety, or in part, been submitted at any university for a degree.

Acknowledgements

I would like to thank all persons, who, somehow, supported the successful work of this thesis.

There is especially the Chair of Factory Organization, who made the stay in South Africa for a thesis possible. At Indutech (Pty) Ltd, I thank especially Professor Niek du Preez as the head, for supervising me in a concerned way, despite the little time he had available, and Bernard Katz, for all the assistance and advices he gave to me. Further I am especially grateful to all colleagues of Indutech (Pty) Ltd who made it a very nice time in South Africa.

Lastly, and most importantly, I wish to thank my parents, who gave me the possibility of studying and composing my thesis in a foreign country.

Abstract

The design and development of general Product Life Cycles (PLC) and Enterprise Life Cycles (ELC) has received significant attention over the past years. The EDENTM Software Environment developed from Indutech (Pty) Ltd provides roadmaps for both life cycles. These roadmaps allow the involved development team to follow a predefined step-by-step structure for their respective project.

As a PLC always belongs to a superior ELC, both life cycles cannot be considered independently. Changes and decisions of one of the life cycles usually have an impact on the other. And although the PLC and ELC are well explored, there does not exist a model which reveals those important interfaces between both life cycles.

This thesis aims on the detection of impacts of the PLC on the ELC. As the Design Review (DR) is a crucial key control element in the development process, the detection of the links is done by means of such DR. After giving general information about DR and providing definitions and descriptions of DR in the PLC and ELC, an impact-matrix is developed which shows the detected interference of the ELC by decisions of DR conducted in the PLC.

CHAPTER 1: Introduction of the Thesis

1.1 Introduction

It is generally acknowledged that companies today face a dynamic environment, changing at an increasingly rapid pace /VOLB96/ /AVEN94/. To maintain competitiveness, the engineering team involved in the product development process is forced to develop cheaper, better, innovative, and more importantly, faster. The requirements of shortening the time-to-market and quickly adapting to rapidly changing customer and market needs have a huge impact on the Product Life Cycle /MORI99/.

On the other hand also the whole enterprise keeps changing. Nothing is permanent in the business, manufacturing practice, organisational structure or in the information technology infrastructure of an enterprise, not even for months. The design of an enterprise may take a long time and involve many people. As a matter of fact enterprises change more often than the design of any product, and often decisions within the product development are the cause of these changes /BERN94/.

In Figure 1-1 the relations between customer, product and enterprise are illustrated. The customer or the market determines requirements for the product. And the developed product-solution according to the customer requirements again determines the requirements for manufacturing the product within the enterprise. For instance the application of innovative materials for the product-solution implies the correct handling of those materials. This involves acquisition of new technologies and equipment and training of personnel on the new equipment.

The considerations show the strong interactions between the product and its appropriate enterprise. Although the Product- and the Enterprise Life Cycles are well known, defined and explained, and innovative roadmaps of both life cycles for guiding the design team step-by-step through the design process are provided, the interactions between the life cycles are still quite unexplored.

illustration not visible in this excerpt

FIGURE 1-1 CUSTOMER-PRODUCT-ENTERPRISE RELATIONS

1.2 Objectives

The Design Review (DR) represents an important key control element of a life cycle. The decisions made during this review have an impact on several areas of the entire enterprise environment.

The first objective of this thesis is to provide a generic definition and description of DR for the Product Life Cycle (PLC) and the Enterprise Life Cycle (ELC), which can be used for product development and enterprise establishment.

In the next step those information is used to determine interactions and impacts between both life cycles by means of DR conducted in the PLC. The results can be used to be aware of effects decisions in the PLC have on the enterprise and to predict in early development stages of the product its impacts on the ELC (e.g. allow to make statements in the Concept Phase of a product about its resulting influences on the Design- or Construction Phase of the ELC).

1.3 Structure

First the thesis gives general information about DR including definitions, purposes and benefits of those reviews. Furthermore, the structure of the involved review team is pointed out and information about conducting those reviews and about the function of checklists is provided. Then the PLC and the ELC with their respective phases are introduced prior suitable definitions of all DR in both life cycles are presented. Afterwards the different areas of impact of the DR are explained. With this information the interfaces between the PLC and ELC can be detected by means of DR conducted in the PLC. These considerations build the main part of the thesis.

The overall structure of the thesis is illustrated in Figure 1-2. In the figure three different layers allow the assignment of the several points to an area of general considerations and information, to the PLC or to the ELC.

illustration not visible in this excerpt

FIGURE 1-2 STRUCTURE OF THE THESIS

CHAPTER 2: Design Review - A Key Design Control Element

2.1 Introduction

Historically, the major influence in setting product specifications has had the product design department. With the development of increasingly complex products and the ever-larger capital commitments required for their manufacture, it has become necessary to broaden the responsibility for determining specifications. The implementation of DR and the establishment of a DR team is a prevalent response to this acquirement /ANDR92/.

Today, the DR methodology is widely used and endorsed in commercial industry. In fact, 89% of the companies surveyed in a recent benchmarking study of 72 leading companies in seven basic industries reported that they are using DR as a design assurance tool /CRIS97/.

This chapter introduces the DR as an important key for controlling quality in the development.

2.2 What is Design Review?

The aim of this chapter is to introduce the DR as an essential part in the PLC and the ELC and to provide general information about definitions of DR or involved people.

2.2.1 DO and CO and the need for DR

Every process, whether it is on high level as the whole PLC or ELC, or on a low and detailed level as any separate step or sub-step within a phase of any global lifecycle, is characterized by its corresponding objectives. These objectives, at which the process is aiming, are defined prior the start of the appropriate process and can be divided into the Design Objectives (DO) and the Control Objectives (CO) as shown in Figure 2-1.

illustration not visible in this excerpt

FIGURE 2-1 DISTINCTION BETWEEN DESIGN- AND CONTROL OBJECTIVES

The DO describe the real goal of the process, can be measured and quantified with appropriate indicators and are set by the design team. The CO show the design team the best way how to achieve the DO and how to manage all the resources (people, materials, documents…) in the process.

So the DO align the design processes and prompt the design team to keep certain design criteria (which are largely determined by customer requirements) in mind when doing an engineering exercise, while the CO comprise the management of the DO.

At the end of the process a review has to be executed in order to check if all the objectives have been reached. This review is called the DR. Figure 2-2 depicts the design process, the objectives of the process formulated at the beginning of the process and the controlling DR at the end of the process.

illustration not visible in this excerpt

FIGURE 2-2 THE DESIGN PROCESS

2.2.2 Definitions of Design Review

In the literature appear various definitions for DR, depending on the review’s level of detail or the area where the review is implemented. Beside this, there also exist definitions, which provide a general description of a DR:

“The term ‘design review’ designates a documented, comprehensive, systematic examination of a design and its development to evaluate the adequacy of the design input requirements, evaluate the capability of the design to meet those requirements, and identify problems in the design or development program.” /CLIN02/

Thompson defines in /THOM99/ a DR as “the quantitative and qualitative examination of a proposed design to ensure that it is safe and has optimum performance with respect to maintainability, reliability and those performance variables needed to specify the equipment”.

In /INDU01/ a DR is defined as “a formally documented and systematic critical study of a design or its products at specified points in a system design, or development, and is distinguished from a progress meeting which discusses status, time-scales, and cost”.

2.2.3 Purpose of Design Reviews

Design reviews can be conducted for different reasons. However, the main focus should always be to test at key points during the project by an interdepartmental group, if the requirements defined in the DO (e.g. customer requirements) and CO (e.g. budget, time schedule) are being fulfilled. Here the formal DR meeting is used as a means for the Business Management Team, Product Manager, Product Development Team, Team Leaders, every other developer, and the customer, if present, to assess the design output. Other reasons (which should be secondary) may include education (of other team members and if present the customer), a springboard for new ideas (brainstorming) or to review the performance of a subcontractor /LOUW01/ /CLIN02/.

From the perspective of management, DR are discrete events which are used to monitor progress, to provide formal feedback to management, as well as to submit proposals for forthcoming work /MULL00/.

In /CLIN02/ are summarised four primary functions of DR:

- Provide a systematic assessment of design results, including the product design and the associated design for manufacturing and product support
- Provide feedback to designers on existing or emerging problems
- Assess progress of the development program
- Provide confirmation that the development program is ready to move to the next phase of development

The DR forms a crucial communication link between staff engaged in the various activities to ensure that the requirements are being met before a successful system can be delivered to the customer. Most attention shall be paid to areas that contain unfamiliar problems, and outside consultants may be called in to comment. The design review meeting will make a number of recommendations and a number of new points will be formally recorded; the designer is required to take note of this advice but retains the authority and responsibility for making the final decisions. However, it will not alter the principle that the designer (design authority) is responsible for the design /INDU01/. The DR should help the designer and enrich design activity, it is an integral part of design activity and not a ‘bolt-on’ extra. This formal technical review aims to satisfy senior management and the customer, ensuring that the design will satisfy all aspects of the requirements (fixed in the DO and CO). It is a critical, co-operative examination, first of the design concept, later of its detail and finally of its suitability for production and use /CHEN02/ /MULL00/.

The specific benefits associated with a good DR methodology are summarized in /CHEN02/ and include:

- Added assurance that the voice of the customer has been heard correctly
- Reductions in design cost and time-to-market
- Reduced likelihood of program delay due to unexpected problems
- Improved overall design integrity
- Prevention of problems and associated downstream costs
- Increased standardization
- Improved customer satisfaction
- Increased program structure and control.

Offering all these benefits, the DR is a widely used method in commercial industry.

2.2.4 Design Review Teams

DR meetings are planned, conducted and recorded by the DR team. This team shall include members of senior management, the design/development team, quality assurance, configuration control; when appropriate, they may include staff from purchasing, installation and maintenance. As an adequate assessment of a particular design may involve a number of disciplines such as optics, electronics, mechanics, software, ergonomics, etc. as well as manufacturer and customer considerations affecting the design, it has to be ensured that this personnel is appropriately qualified /MULL00/ /CLIN02/.

The chairman of the DR, who selects these individuals and is responsible for the planning to the recording of the DR, must further ensure that the extent of an individual review on the one hand stays in a manageable scope, but on the other hand still allows comprehensive assessment of the design. The understanding tendency to include extra staff at the review meeting, 'just in case', leads to large meetings which can be inefficient and expensive; so whenever it is possible the numbers attending design reviews should be restricted to ten.

The team has at least one independent individual without direct responsibility for the design or phase under review. If possible, all the other members of the team are familiar with the details of the project, but also not directly involved in design development for the project. The competency of the members in the DR should be adequate to permit them to examine designs and their implications. All participants are expected to brief themselves thoroughly and probe for weak spots in the design, but at the same time to maintain self-discipline and objectivity /CDRH96/ /MULL00/.

The DR team has sufficient authority to make decisions, provided that the design remains within the overall constraints, such as /CDRH96/:

- to decide on and confirm the solution to be adopted
- to change the course of design
- to change the design input requirements
- to recommend additional research activity
- to conditionally accept results in accordance with established procedures

A typical example of a DR team, including personnel and their responsibilities, is shown in Table 2-1. Here the DR process has been subdivided into three phases, and each phase is an update of more detailed analysis based on the latest knowledge.

TABLE 2-1 DESIGN REVIEW TEAM MEMBER /KAPU92/

illustration not visible in this excerpt

2.2.5 Conducting DR

The DR involves a number of different discipline areas and covers a wide variety of data design. In order to successfully conduct this review, it must be well organized and firmly controlled by the chairperson of the DR team. DR meetings should be brief and to the point and any drifting away from the topics on the agenda has to be prevented. Further the attendance of the DR team should be limited to those having a direct interest and who can contribute to the subject matter being represented. Finally, the DR has to make provisions for the identification, recording, scheduling, and monitoring of corrective actions /BLAN86/.

2.2.6 Number of DR

During the different phases of the design process occur specific types of reviews (the different types of DR are introduced in CHAPTER 3). Depending on the complexity of the development project and the extent of the design requirements the number of reviews of the same type may vary. For instance, a complex product design may require several technical DR to complete a review of verification activities and design output for all subsystems and technical disciplines. Further it is important to care for a limited scope of an individual review to something reasonably manageable within the allocated time, because reviews that are overly long become self-defeating /CLIN02/.

2.2.7 Checklists as a tool in DR

The checklist function as provided in the software environment EDENTM can be used for DR purposes to ensure that the correct design actions, procedures and design paths were followed (apart from specifying certain actions to be carried during design steps, specific tools to be used can also be specified in the checklists) /INDU01/.

In the roadmap-structure of the EDENTM software checklists are used to ensure the comprehensive completion of a step. Each step in a life cycle has a list of tasks, which has to be completed and ticked off before the step can be considered finished. In Figure 2-3 an example of a checklist-window used in EDENTM is illustrated. The window also displays the progress on specific tasks. Clicking inside the box corresponding to a specific task, assigns a completion tick to that task.

illustration not visible in this excerpt

FIGURE 2-3 EXAMPLE OF A CHECKLIST IN EDENTM /EDEN03C/

By following the checklist the user of the EDENTM software ensures that all the necessary work is done for the currently activated life cycle step. Typically, users will regularly tick off the tasks completed. This ensures that none of the steps are skipped in the process of completing a project /EDEN03c/.

2.3 The Product- and the Enterprise Life Cycle

2.3.1 Introduction

In order to understand the definitions and descriptions of the DR applied in the PLC and the ELC and provided in CHAPTER 3, it is necessary to introduce both life cycles first. The following two chapters present each the PLC and the ELC and their appropriate phases. Finally, in CHAPTER 2.3.4 the involvement of both life cycles is discussed.

2.3.2 Product Life Cycle

The PLC describes the whole life cycle of a product, from the first idea to the disposal of the product. The PLC can be divided in several phases. In /FISC03/ the PLC consists out of eight different phases as it is shown in Figure 2-4.

illustration not visible in this excerpt

FIGURE 2-4 THE PRODUCT LIFE CYCLE

These phases are defined as followed:

1. Concept Phase

The Concept Phase marks the initiation of a PLC. During this phase new ideas are created through customer demands and market opportunities. Both of these are influenced by research into new technologies and market requirements. Customer and market needs are changing rapidly and opportunities arise from these changes. These new ideas are considered against the basic operational policies of the company for preliminary evaluation. The Concept Phase includes comprehensive literature and patent searches, competitor analyses and reverse engineering considerations.

The fundamental purpose of this phase is to develop a design concept that will meet the client's cost and performance requirements. Regular interaction with the client in this phase ensures a mutual understanding of what is required and what can be delivered. There is a high failure rate of projects during the conceptual phase. Rightly so, since the study process conducted, during this phase projects have to be identified that have a high risk and are technically, environmentally, or economically infeasible or impractical, taking into account that even during the concept phase, market shifts are often experienced /EDEN03a/.

The deliverables of the concept phase include:

- Analysis of competitors' products
- Report on appropriate published literature
- Preliminary schematics for electrical/electronic systems
- Preliminary software algorithms
- Preliminary mechanical design
- Provisional costing estimates

2. Definition Phase

During the Definition Phase characteristics of the product and its requirements are generated out of the information gathered in the Concept Phase and a functional design of the product is provided.

The major objective of the Definition Phase is to determine as soon and as accurately as possible a realistic schedule, costs, performance, and required human and non-human resources. For the further development it is necessary to consider if all the involved elements and subsystems fit together, economically and technically, within the limitations of the environment. The phase addresses the classic what, when, how and who scenarios, and provides the development team with more concrete detail about the activities to come.

The Definition Phase allows the project team to fully conceive and define the product before its introduction to the enterprise environment. This phase provides the opportunity to examine and confirm decisions regarding continued development, possible prototypes and testing. The production, logistics, service, maintenance and eventually recycling of the product is considered, as well as other processes that are necessary to create the product. So a foresight to one of these steps might be required.

The phase includes the following:

- Firm identification of internal and external requirements
- Preparation of final product performance requirements
- Determine realistic cost implications
- Determine realistic sales schedule
- Identification of areas of high risk and uncertainty
- Quantifying all necessary support systems
- Initial preparation of documentation required to support the product

3. Design Phase

The aim of the Design Phase is to move from the concept baseline and the basic functional design determined in the Definition Phase to the detailed product baseline that supplies a complete and detailed description of the verified product. The Design Phase concretises the assumptions of the Concept Phase, combining them with the definitions made in the second phase, in form of part lists, drawings and work instructions. Herewith are linked engineering processes, which convert the functional requirements of the definition phase into design parameters. These parameters can be translated in variables that are providing the final prototype-ready data-packet. Testing and trials of sub-systems (as required) and the prototype throughout the duration of this phase verify the design.

Designing is an activity that recognizes the goals or purposes of products or systems. It shapes its objects - creates their forms, and implements their functionality - in accordance with the goals or purposes of those objects. The entire design process summarises those activities involved in creating the styling, look and feel of the product, deciding on the product’s mechanical architecture, selecting materials and processes, and engineering the various components necessary to make the product work.

The process of design includes:

- Define part geometry
- Specify materials
- Define tolerances
- Industrial design control
- Documentation
- Define processes
- Design tooling
- Begin tooling procurement

The design process can be divided into the four components preliminary design, preliminary design testing, detailed design and final prototyping. Possible production methods shall also be considered and an initial cost model shall be developed.

4. Industrialisation Phase

The Industrialisation Phase plans the premises and requirements of the Production Phase. It is the connection between the development and the production of the product. During this period the implementation of the manufacturing processes and the therefore required resources are calculated. From forecasts and customer orders, production planning determines the human and material resources necessary to produce the array of products demanded in an efficient manner. The goal is to effectively allocate detailed system capacity over a designated time horizon.

The Industrialization Phase sets up the industrial environment to produce the product. These planning activities, especially the production and capacity planning, necessitate the consideration of the other products and their requirements and resources. Interactions or correlations to other products aggravate the delimitation between the Industrialisation and the ELC.

A structured approach to production requirement planning is as follows:

- Determine organisational policy regarding controllable variables
- Establish the forecasting time period and horizon of the production plan
- Develop the demand forecasting system
- Select an appropriate unit of aggregate capacity
- Determine the relevant cost structures
- Plan the required resources

5. Production Phase

The Production Phase converts process variables into tangible products by implementing the decisions made and directing energy and information according to the design data-pack.

Production in a manufacturing environment deals with constructing, installing and scheduling of manufacturing processes, in harmony with the necessary enterprise resources and support systems.

This phase typically includes the following fields:

- Ramp-up of manufacturing processes
- Production planning
- Scheduling and production control
- Execution of production and supply of required resources
- Inventory control
- Maintenance of production equipment

The Production Phase is the point where the product leaves the opportunity region of the PLC and gets into the operative market fulfilment phase.

There are many decisions that need to be made and questions that need to be answered before the beginning of implementation. One should not be tempted to shortcut this process if the system is vital to the organization. It is important to know what resources (people and time) are required, and when.

It is a good idea to identify milestones and key successes factors in the planning process, and monitor these throughout the implementation. This makes it easier to check the progress along the way and take corrective action if necessary.

6. Distribution and Logistics Phase

This phase is considering the movement of goods from the production to the customer, which can be either an end consumer or a manufacturer in a further production stage. The phase also includes the consideration of the corresponding information flow. It deals with the non-value added operations of spatial movement, time and quantity adjustment of the product after it leaves the production phase.

The purpose of a logistic system, especially distribution system, aims to transfer the product to point of consumption for the purpose of conforming to customer requirements. The objectives can be characterised as:

The delivery of the

- Right goods
- In the right quantity
- In the right quality
- At the right time
- To the right place
- At the right price

Traditional functional organisational structures may not have a single organisational unit for managing the total logistics process. Logistics functions are, as a result, divided into the traditional functional units such as marketing, purchasing, production and distribution.

A typical list of elements within a total logistics system might include:

- Facility/warehouse locations
- Demand forecasting
- Inventory planning and control
- Warehousing and storage operations
- Procurement and purchasing
- Commissioning
- Packaging
- Transportation
- Customer/Supply service
- Order processing
- Salvage and scrap disposal
- Supply Chain Management

7. Product Support and Maintenance Phase

This phase of the PLC considers the actions that deal with the product as it enters the market. This includes ensuring a sustained interaction with the product in order to support it and keep it performing as expected during its useful life. Maintenance of the sold goods, product recalls, warranties, updates or any other kind of product support or service have to be provided.

The executed actions in this phase focus more on the service related to the product than to the core product itself. Product support is essential for achieving customer satisfaction in many industries, including high-tech sectors such as computing as well as "low-tech" sectors such as domestic appliances and the like. Leading companies recognize both the importance of product support and the significance of evaluating support requirements at the design stage by using Design for Supportability techniques. This enables them to gain competitive advantage from customer support and earn significant revenues. Benchmarking should also be considered as part of this process.

8. Disposal Phase

At the end of the PLC, the Disposal Phase deals with the dissolution of the product. It prepares the enterprise to phase-out the specific product, and to accept responsibility for the existence of the product. The purpose of the Disposal Phase is to make sure that the product is appropriately recycled or respectively disposed.

This phase is executed for environmental purposes but saving resources can also be profitable.

There are three main factors in the disposal phase. While the first one affects the product line, the second one concerns the single product units. The third aspect considers components and materials of a product, which have not been used and have to be disposed of in a responsible manner.

Product phase-down occurs when the decision is taken to discontinue the product line. This is usually the case when there is not enough demand to cover the costs of further production. It is always important to see the single product line in the context of the whole company. The overall effect has to be taken into account, because the disposal of one product line may affect other lines of production (also of outside companies if the product is used as a subsystem) or have a negative effect on the company's image.

In the roadmap structure of the PLC in EDENTM /EDEN03a/ the mentioned phases are further divided in different steps, which again consist of several sub steps.

2.3.3 Enterprise Life Cycle

Like the PLC describes the whole life cycle of a product, the ELC shows the entire life cycle of an enterprise divided into different phases. The six phases of the ELC are depicted in Figure 2-5 and further described in the following /WILL01a/ /EDEN03b/:

illustration not visible in this excerpt

FIGURE 2-5 THE ENTERPRISE LIFE CYCLE

[...]