What is it about?
A key requirement, in a distributed product development environment at General Motors, was to provide a series of quantitative and qualitative mechanisms for integrating competing information from distributed agents. Such mechanisms must also account for provisions for combining different opinions, for resolving conflicts, and for finding a feasible or optimal solution at the end. We, at Electronic Data Systems (EDS), General Motors Account, developed a Decision-based Integrated Product Development (DIPD) methodology to capture a system-level optimization formulation as part of a product design, development and delivery (PD3) process. The paper describes this methodology in the context of system-level optimization. DIPD employs the inputs, requirement, constraints, and output conventions to formulate the product realization problem in a distributed manner. The purpose of this DIPD methodology is to improve the performance characteristics of the product, process, and organization (PPO) relative to automobile consumer needs and expectations. © 2002 Wiley Periodicals, Inc. Syst Eng 5: 123–144, 2002, link to the abstract: http://onlinelibrary.wiley.com/doi/10.1002/sys.10008/abstract
Featured Image
Why is it important?
DIPD builds the theory through a systematic revision and extension of the paradigms introduced earlier by optimization experts and practitioners including this author [Prasad, 1996]. The eight parts of this DIPD methodology, called building blocks, are discussed at length in this paper. The first four blocks, 1–4, provide a conceptual framework for understanding the challenges and opportunities in DIPD. The last four parts, 5–8, of this methodology provide the building blocks for an analytical and conceptual framework for decision-making, PPO improvements, and a large-scale system optimization. DIPD is described as the process of going from a set of incomplete and inconsistent product requirements to realizing a physical product [Prasad, 1997]. As stated earlier, this methodol¬ogy has eight parts to it. Each part contributes to the overall effectiveness of the DIPD process. These parts are listed here and shown graphically in Figure 2. 1. Product Requirements Planning & Management 2. Work Structuring & CE Team Deployment 3. Methodology Systematization 4. Product and Process Systematization 5. Problem Identification and Support System 6. Integrated Problem Formulation 7. Collaboration and Cross-functional Problem Solving 8. Continuous Monitoring and Knowledge Upgrade
Perspectives
The product environment in modern manufacturing is commonly very complex. It consists of many components of products, processes, organization (PPO) and services, including information services (hardware, communication network and CAX (computer-aided “X”-ing software). Where, X (in CAX) can take several values like "analysis," "Design", Engineering", "Manufacturing, etc. If X= "Design," then CAX means CAD software. If X = "Engineering", it is CAE software. If X = "Manufacturing", then CAX becomes CAM. The design of an automobile at General Motors, for example, contains 2000 to 3000 parts, and involves thousands of engineers making millions of design decisions over its life cycle. None of these parts are designed and developed in isola¬tion from each other [Eppinger, 1994]. Beyond concurrency of the decomposed tasks, integration of distributed PPO (product, process and organization) environments seeks to offer better life-cycle alternatives and product realization potentials. The product realization taxonomy described in [Prasad, 1996] establishes a methodology of systematically organizing the process necessary for new product realization and for developing future product upgrades [Berger, 1989]. Though this process taxonomy is useful for formulating and decomposing a system [Kusiak and Wang, 1993]. However, the taxonomic concepts do not take the work-groups to the next step, i.e., to synthesize or to optimize the system with respect to an identified set of Product, Process and Organization (PPO) constraints. Such a formulation is called herein PPO design system. Taxonomy characterizes the PPO design system problem into a well-structured set of decomposed tasks. This means a taxonomy use converts the PD3 process into a topology of networks showing how tasks are interconnected or even coupled [Prasad, 1996]. However, such taxonomy does not show how the network of tasks will be solved.
Dr Biren Prasad
Panasonic Avionics
Read the Original
This page is a summary of: Building blocks for a decision-based integrated product development and system realization process, Systems Engineering, January 2002, Wiley,
DOI: 10.1002/sys.10008.
You can read the full text:
Contributors
The following have contributed to this page
