Extension of Manufacturing System Design Decomposition to Implement Manufacturing Systems That are Sustainable

In the global business environment, a manufacturing enterprise has to take into consideration multiple performance measures in systems design and operation. Some commonly identified performance measures include product functionality, quality, lead time, cost, productivity, adaptability, and sustainability [1–4]. All of these performance measures are dynamic, which vary with respect to time. Therefore, manufacturing systems must be evolved continuously to achieve the optimized system performance over time. The long-term growth of a manufacturing system relies on its commitment to continuous improvement (CI). CI is a philosophy of sustained improvement and the elimination of waste for all aspects of the manufacturing system and processes [5].

Many methodologies have been proposed to support CI of manufacturing systems. Bhuiyan and Baghel [5] provided an overview of the history, evolution, and available CI design methodologies, including lean manufacturing, total quality management (TQM), Six Sigma, just-in-time (JIT) management, Jidoka, and a hybrid approach [6]. One of the most powerful tools is six sigma, which is widely used to collect data for the elimination of waste and process variation, but focuses on the improvement of single operations [7]. The Toyota Production System (TPS) is well known as a successful system application; the Art of Lean Inc. [8] gave a brief history of the development of the Toyota Production System as well as the basic principles and techniques regarding the operation of manufacturing systems. The research on the methodologies and techniques of CI has drawn attention to the research community, and much progress has been made. For example, instead of focusing on system performance, Kovach et al. [9] suggest collecting data through surveys which were administered across multiple industries to identify the areas for CI. Hernandez-Matias et al. [10] combined the hierarchical structure, quantitative/qualitative analysis, data modeling, and manufacturing database and performance indicators as an integrated modeling framework to analyze and diagnose a manufacturing system. Dulhai [11] and Sweta [12] discussed using Sort, Set in order, Shining, Standardize, and Sustain (5S) approach in engineering practice to improve the business environment. Romaniello et al. [13] proposed a methodology consisting of four phases including monitoring, analysis, action, and review. The approach could be applied for maintenance and quality management in customer-oriented manufacturing systems. Smit [14] emphasized the importance of the organizational culture in CI of medium-sized companies in transition; the factors of accountability, communication, and system perspectives were taken into account.

Adopting advanced information technology (IT) such as internet of things (IoT) and cloud computing supports the continuous evolution of manufacturing systems in a dynamic environment [15,16]. The most recent progress has been reported in a special issue of the journal of manufacturing science and engineering [17], and Wang et al. [18] have analyzed the benefits and limitations of using cloud manufacturing. For example, Yang et al. [19] discussed the challenges of health monitoring and prognostics of machines in a heterogeneous environment and proposed a framework to implement a health surveillance system based on IoT and Big Data. Ren et al. [20] emphasized the importance of system interactions in cloud manufacturing; they surveyed the models and existing technologies which can be applied to develop cloud-based smart user interfaces. In optimizing machining processes, Tapoglou et al. [21] integrated conventional functions blocks and real-time monitoring with cloud computing to achieve the global optimization of machining processes. The trends of technology development on cloud manufacturing have been explored extensively by Buckholtz et al. [22].

While the previously mentioned research has focused on enabling technologies in the information flow, this paper is especially interested in the connection and complexity of information flow and material flow in the design of manufacturing systems. One of the most promising approaches to deal with such complexity is axiomatic design theory (ADT). ADT provides a valuable theoretical framework to guide designers through the design process to achieve optimized performance for required functions. ADT was proven an effective approach to meeting goals for continuous improvement of product or system development [23]. ADT established a scientific basis for engineers to design and improve products and systems based on logical and rational tools. Gu et al. [24] provided a comprehensive review of the application of ADT in an adaptable design aimed at creating product designs to achieve different functional requirements. The authors found that even though engineering committed 80% of the product cost at the design stage, the design consumed only 20% of the product development effort [24].

As ADT itself is still under development, numerous efforts have been made in extending ADT and deploying ADT to new applications. For example, Bahadir and Satoglu [25] compared different techniques for decision-making processes, and it was believed that ADT had outperformed other methods. They observed the recent developments in ADT and chose it to select robots for given applications. Many design parameters for industrial robots were defined, and ADT was applied in their decision support system to select most suitable robots for a given set of design criteria. Shi et al. [26] argued that ADT was a natural choice to take into account the eco-factors in defining the functional requirements and design parameters in the design of an eco-friendly manufacturing system. Malaek et al. [27] suggested using well-defined ADT to overcome the shortcomings of other conventional design approaches to eliminate the couplings of “cost” and “complexity” with system requirements. Chen [28] deployed the ADT and lean techniques to improve the efficiency of a production line for a medical company. The identified design parameters for system efficiency included manpower management, cycle time, visual management, inventory, and floor area. Sun and Cheng [29] extended ADT to design a generic modular reconfigurable system; the methodologies based on ADT were implemented in a Java-based environment. Franco and Batocchio [30] developed an axiomatic framework for the design of holonic manufacturing systems. Aganovic [31] integrated the workshop design konstruktion (WDK) and ADT as a unified approach to design products and manufacturing systems concurrently. Kandjani et al. [32] discussed the complexities involved in global software development projects, and they proposed to use the extended ADT to reduce the complexity at the project planning stage and minimize the complexity at the project execution stage. Transportation systems require continuous evolution to accommodate the needs of the passengers and freight; Baca et al. [33] explored the possibility of using ADT for passenger itinerary enumeration in reconfigurable transportation systems. Masmoudi et al. [34] discussed the research challenges in cellular manufacturing (CM), and they further combined ADT and experimental design to generate feasible system solutions. Celik and Er [35] introduced the fuzzy theory to determine the mapping of matrices from design parameters to functional requirements; it was further deployed in the model selection to achieve the solutions with a high level of consistency in Operations Research. Kandjani and Bernus [36] treated a complex enterprise as a system of systems. Each component in the system has a recursive, self-designing property, and the axiom of recursion was introduced in ADT to deal with the complexity of a system. The axiom of recursion was to distribute the design authority between systems on each level.

Designing and operating a manufacturing system should be an iterative process of fitting the system confirmation and operation to production needs arising from market demand [37]. Manufacturing systems must sustain relevant changes and desired product variation; therefore, the changes and variety in products are strongly interconnected with the continuous improvement of manufacturing systems themselves [38]. One particular focus in manufacturing industries was to improve the operations of manufacturing systems and engineering design while less effort has been conducted to connect environmental changes with system improvement [39]. Functional requirements (FRs) are defined as the minimum set of independent requirements, which completely characterize the functional needs of the customer.

Existing principles, methods, tools, and techniques for CI can be applied by practitioners to provide guidance in implementing a CI program or methodology [5]. However, conventional analysis on qualitative variables lacks the level of detail to identify specific CI areas [10]. It was surprising to note that many companies failed to sustain improvement efforts or never even get off the improvement starting blocks; it was not for a lack of methodologies since over 80 percent of U.S. manufacturers have an improvement approach in place [40].

ADT establishes a scientific basis for systems design. ADT is based on two axioms, which differentiate between acceptable and unacceptable system designs. The Independence Axiom states that when there are two or more functional requirements, the design solutions must be chosen so that each functional requirement is satisfied in a predictable way. The information axiom states that the detailed design solutions selected should have the highest probability of requirement achievement [41]. Design parameters (DPs) are the key solutions that logically satisfy the specified set of FRs. The way in which the DPs affect the FRs determines whether the design is predictable and whether the independence axiom is satisfied. As shown in Fig. 1, Axiomatic design involves an interplay between what we want to achieve in the functional domain (FRs) and the physical implementation in the physical domain (DPs) that we choose to achieve the FRs.

Cochran created a framework with Lockheed Martin Engineers called the product delivery system (PDS) map, which represents the design for a stable manufacturing system that operates with the fewest resources that were built on the previously published manufacturing system design decomposition (MSDD) [42]. The PDS map represents a system design in its entirety. Every FR must be achieved for the design to be complete. The goal of system design is to achieve each FR with the least use of resources over the system life cycle. W. Edwards Deming stated, “Management objectives cannot be met by unstable systems” [43]. Cochran defines the seven functional requirements (FRs) for system stability derived from the MSDD as:

FR1 Provide a safe, healthy environment—The Foundation.

FR2 Produce the customer-consumed quantity every time interval—from JIT.

FR3 Produce the customer-consumed mix every time interval—from JIT.

FR4 Do not advance a defect to the next customer operation—from Jidoka.

FR5 Achieve FR1 through FR4 in spite of variation—Robust Design.

FR6 When a problem occurs in accomplishing FR1 through FR4, rapidly identify the problem condition and respond in a standardized (pre-defined) way—Controllable.

FR7 Only once FR1 through FR6 is achieved (the system is designed to become stable), produce products with least time in system—Reduce cost further by reducing Standard Work in Process Inventory and additional waste(s).

A variety of writings [27,42,44–46] discuss the successful attributes of manufacturing systems. Figure 2 illustrates how the PDS incorporates the six requirements for system stability [47].

The PDS is a path-dependent design and demonstrates the importance of the knowledge of path dependency in manufacturing system design. Path dependence indicates that a DP affects the achievement of multiple FRs. Figure 3 graphically demonstrates that the high-level branches of the PDS are path dependent.

Industry traditionally lacks a scientific basis for determining the minimum requirements and critical solutions to achieve a stable and efficient manufacturing system. Therefore, many companies struggle to meet the six requirements of system stability by throwing resources into successive waves of “improvement projects.” This kind of spending leads, consequently, to higher manufacturing costs [48,49]. The PDS provides a scientific basis for identifying and selecting improvement projects that will fulfill requirements without increasing costs [50].

Since the PDS defines the requirements that an ideal manufacturing system design must meet, the team used a questionnaire as an assessment instrument to evaluate the health of the current system [51,52]. The survey determines how well the existing manufacturing system achieves each FR stated by the PDS. The approach to achieving long-term sustainability of the manufacturing system assumes that when the system achieves each FR entirely, the system is stable. Minimum cost is the result of implementing a stable system design and continuous improvement [53]. Only when the manufacturing system is stable, can waste, which is the source of excess cost be permanently reduced [48–50]. DP implementation to fully achieve an FR may require additional investment and resources. Industry commonly assumes the cost/investment of fully implementing a DP to be prohibitive. Thus, companies unknowingly and inevitably have much higher cost resulting from system instability (e.g., fighting fires, expediting, holding “what-can-we-make-today meetings,” making defective products, etc.) [43].

Collective system design (CSD) is a methodology that addresses the problems that many enterprises face in implementing and sustaining the Toyota Production System, Lean and Lean-Six Sigma. Evidence in the application of lean as it is being taught and applied today is that “lean” is sustained in less than ten percent of the implementations after three years [54,55].

To illustrate one of the reasons why “lean” is not successful is that leaders and managers copy the physical tools or “how's” of the Toyota Production System without an understanding of the intended purpose for the use of the lean tool. Figure 4 illustrates the use of an Andon board at the Toyota Tsutsumi Plant in Aichi Prefecture, Japan. The logic that may exist in many “lean” implementations is, “since the Andon Board is an important part of lean, we should implement the Andon Board.”

The implementation of the Andon Board is called a physical solution (PS) in collective system design. Axiomatic design theory calls a PS a design parameter (DP) [41]. These terms are names for the selection of the how's in the physical domain to achieve a functional requirement (FR) in the Functional Domain. The functional domain communicates what the system designers intend to accomplish, sometimes called the design intention. The functional domain does not define a solution; instead, the physical domain states a solution that is proposed to achieve an FR. The proposed solution is called a PS by collective system design.

When observing the Andon board as a known PS, a system designer may ask the question, “What is the Functional Requirement that the Andon Board satisfies?” This type of question uses Axiomatic Design to communicate the thinking about an existing design.

Andon means “light” in Japanese. In many assembly plants, the Andon Cord is pulled to stop a line when a problem occurs. For this design example, the Andon Board is situated above the manufacturing cell shown in Fig. 4. Each machine in the cell operates with a cycle time of less than or equal to the takt time of 54 s/unit [56]. Also, the cell has two operators who run multiple machines in work loops. Likewise, the cycle time of each operator is designed to be less than or equal to the takt time (with a 5% allowance). The takt time is the average industrial engineering cycle time (time/unit) of production that is required for the manufacturing cell to meet customer demand. The Andon Board provides a display (row 1, in the upper part of Fig. 4) that defines how many parts have to be made at a given time during the day. The second row defines how many “actual parts” have been made. The third row is the “percentage to takt time” measure that displays the actual parts produced, divided by the number of parts that should have been produced at any given time during the production shift. Even with the above explanation, the authors contend that the underlying design intention/FR for the Andon Board's existence as a PS is still unknown to the casual observer of the Andon Board.

When the manufacturing cell is not keeping up with the takt time, one of the yellow lights flashes and music plays to alert the team leader and team members that something is going wrong. One company that implemented an Andon Board as a PS, established the practice when takt time was not being met, to instruct operator to enter a “reason” code into a computer system. Using the precept of FR and PS to communicate the design of an existing system, the implied FR is, “Record Downtime Event.”

However, at the Tsutsumi plant, the FR is to “Rapidly Identify a Problem Condition and Resolve in a Predefined Way.” [42,57]. At Tsutsumi, when a problem condition occurs, the team leader's standard work is to respond to the musical alarm within an expected time (typically less than 90 s). The team leader then follows a type of triage process to diagnose the cause of the alarm condition to ensure that the proper resources are in place to resolve the problem. The difference in the FR of the system designers' mindset in the two different implementations is in sharp contrast: either to fix the problem or to record that a problem has occurred. Interestingly, the same PS, the Andon Board, was used in both cases.

This example illustrates the need for a language to communicate system design that separates design intent/purpose (FR) from the physical means (PS) that is implemented to achieve an FR. The people in the midwestern company who implemented the Andon Board were not seeking to achieve the same FR as the Toyota Tsutsumi plant. An observer of this situation would then know to ask “why?” Perhaps the leadership team did not understand the actual Tsutsumi FR, or maybe they thought that a standard work triage process like Tsutsumi was not possible in their plant? A language for system design enables communication of design intention and the implementation of a PS as a proposed hypothesis to achieve an FR.

Collective system design seeks to establish the logical construct that is necessary to communicate a design using ADT. The people within an organization can learn together by being able to challenge their assumptions, requirements, and solutions regarding any design. In short, people co-create a system design map, built by constructively asking, “Why?” A language for Collective System Design is fundamental to accomplishing this vision of the learning organization [58,59].

In-depth knowledge of the Toyota Production System is required to understand the thinking about the FR that caused the implementation of the Andon Board as a PS, beyond the understanding that Lean is the elimination of waste [60]. This description is necessary but not sufficient to describe the whole of TPS as an integrated enterprise and manufacturing system design [42,53,61]. As mentioned, the Andon board is in response to a functional requirement to be able to identify a problem condition rapidly and to resolve a problem condition in a predetermined way that lasts for the long term [62].

The key to understanding the Andon board requires the understanding that TPS represents a multi-FR system design. Just in Time is one pillar of the system design that means to produce what the customer wants (regarding quantity and variety) when the customer wants it. Producing the quantity and mix of product that the customer wants are just two FRs of TPS [57].

The manufacturing system design decomposition (MSDD) builds on the theme that TPS is a multi-FR system design [42]. The MSDD uses ADT to describe TPS as a path-dependent design. The MSDD illustrates path dependency; the variability of a product's time in system (σ_t) affects the ability to reduce a product's average time in system (⁠$X¯$_t). The Andon Board as a PS occurs within the Identifying and Resolving Problems branch of the MSDD. Many “lean” implementations work on reducing the average time in system by reducing inventory without reducing the variation in the time in system defined by the MSDD; the MSDD illustrates why this approach is not sustainable [63].

The example of when the manufacturing cell is no longer operating at takt time, that the system has been designed to alert the team leader immediately and the team leader responds quickly to that alarm condition immediately minimizes the variation of a product's time in system (σ_t). When problem recognition is haphazard and inconsistent, the longer that it takes to observe that a problem exists, this variability is increased further when a process is not predefined to resolve the identified problem.

Notice, too, that given the FR: Immediately Identify a Problem Condition and Resolve in Predefined Way relies on designing the physical machines and operators' work to be less than or equal to takt time. Figure 4 illustrates machines/manufacturing processes that are designed (sometimes called right-sized) to takt time [64] further acknowledging the impact of the system requirements for sustainability on manufacturing processes, machine design, and the human–machine interface.

With a language to logically express the designers' thinking about a system, lean becomes the result (or consequence) of the enterprise and manufacturing system design instead of a set of tools to implement [55,59].

Collective system design (SD) is a methodology that embraces design as a logical process of “what” we want to achieve and “how” we plan to achieve it. The CSD framework consists of five elements: (1) the Flame Model of Systems, (2) the CSD Language, (3) the CSD Design Map, (4) Standard Work, and (5) the CSD Map integrated with a plan-do-check-act (PDCA) learning loop [65].

Illustrated by Fig. 5, the Thinking layer of the Flame Model of systems illustrates the thinking about design. Lean thinking may then be defined as a logical design through the use of Axiomatic design as a design taxonomy.

The international council on systems engineering (INCOSE) handbook describes a system as a combination of interacting elements organized to achieve one or more stated purposes [66]. Systems engineering requires the definition of the system boundary. Practitioners of systems engineering may ask, “What is considered to be part of the system at hand and what is external to the system?” The Handbook elaborates that these system elements can include the products, processes, information, facilities, and people. People are not always considered to be within the system boundary but many modern texts on systems engineering neglect to recognize the thoughts and actions of people as part of the system [59]. When considering the enterprise itself as a system, the ideas and actions of people are tantamount to the success and sustainability of a firm [67].

The Flame Model presented in Fig. 5 is used in CSD to communicate the integrated relationships between different views of a system [68]. Cochran and Barnes note, “as with the colors of a flame, the model represents that the parts of the system are not separable from the whole. Often the work (actions) and the enterprise structure (physical system) are the only parts considered in the design because they are more readily observable. However, the thinking and organizational tone are at the core of the Flame Model. While the tone and mindset are harder to observe and diagnose, they should be the basis for enterprise design. Under the methods of CSD, establishing the tone and the thinking is done by determining what the system should achieve through collective agreement of everyone within the system [65].”

A collective agreement about a system design is difficult to achieve without a common language. The purpose of CSD is to provide a means to ensure that everyone has the same frame of reference to express their thinking about the design of a system.

CSD uses ADT to express the thinking layer of the Flame Model of Design [69]. Figure 6 provides the CSD Language to communicate design thinking. A design team must agree on customer needs before determining the FRs of the system. An FR is a customer need that the system must achieve; an FR is not a stretch objective or a nice-to-have. The FRs must not define a solution; this practice is referred to as “solution neutral” design [41]. Only after the set of FRs has been collectively agreed upon is the next step of design taken: propose physical solutions to achieve the FRs. A PS is a proposed means to accomplish an FR. FRs state the “what” and PSs provide the means or “how” of a system design. An important practice in using the CSD Language is that the PSs are each a hypothesis, not a final answer [70].

With the language of CSD, measures are added after the design of the FRs and the PSs. This approach ensures that the metrics are designed to evaluate how effectively the system achieves its FRs. If the measures are determined first, there is a temptation to create FRs that maximize the metrics. However, there is no guarantee that the performance measures and the customer needs are aligned. In addition, by proceeding in this order, an emphasis is made that poor metrics are a result of poorly defined FRs and PSs, and not the failure of the people working within the system.

A PS may not be a discrete element; it may be a system that requires decomposition of its FRs and PSs through the use of the CSD Language. This method of design decomposition results in a network of FRs and PSs called the CSD Design Map. When developed through collective agreement, the map details the shared vision of the people in an enterprise. This vision is also broken down into the individual PSs that will be implemented to achieve the larger or parent FRs. By continuing to apply the design decomposition approach of Axiomatic Design, the CSD Map defines the sequence of PS implementation called path dependence. Some level of coupling may show a natural order of execution while the higher standard of coupling indicates that the design will be difficult to realize and expresses to the designers' that alternative PSs (or even FRs) should be identified.

As each PS is a hypothesis, it is important to treat its application within the system as a type of controlled experiment. The work that the people use to implement a PS must be defined as a procedure with minimal variation; this approach is the concept of Standard Work. Standard Work details the steps to perform a task, including their sequencing and timing, so that the work is repeatable and consistent from person to person.

While Standard Work may identify PSs that do not achieve FRs, to return to the start of the CSD Map is not always necessary. The ability to detect shortcomings and to change accordingly should be built into the system itself. This type of design is self-sustaining and will adapt to the changing needs of the customers, both internal and external. CSD employs a plan-do-check-act (PDCA) Learning Loop as the means of continuously improving Standard Work, a process shown in Fig. 7.

The plan of the PDCA Learning Loop is the Standard Work itself, defined by a PS in the CSD Map. By implementing Standard Work, the work is done consistently, and the results can be checked via the developed measures. In CSD, the Standard Work that describes operation under normal, everyday conditions is referred to as “White Sheet” Standard Work. When the check of the PDCA Learning Loop determines that the Standard Work is not effective, an action must be taken. The details of this action are best included as part of another defined procedure called “Green Sheet” Standard Work by CSD [42]. This Standard Work documents what should happen under abnormal conditions, including levels and the timing of management. As a result of the action in the PDCA Learning Loop, the Standard Work can be improved, or even the choice of PS or FR in the corresponding CSD Map can be re-evaluated. Mr. Ken Kreafle, former Quality Manager for Toyota Motor Manufacturing Kentucky, described Standard Work as “a record of problems solved [71].” Because each improvement is used to modify the Standard Work, the implication is that Standard Work is the best-known way of doing the work right now.

The use of a metric on the FR, FR_m, or a metric on a PS, PS_m, in conjunction with PDCA is illustrated in Fig. 7. Achieving an FR effectively validates the outcome or designers' intention for the system. A metric on a PS verifies that the PS is implemented as the designer intended. This distinction is fundamental to systems engineering and addresses the possibility can be implemented as planned (verification) but does not achieve the intended result (validation).

Cochran and his group worked with an aircraft manufacturing company facing challenging cost targets and having limited available resources. Management was seeking a scientific methodology to define their production system and guide their decision-making.

Data were not readily available on the cost incurred from not fully achieving the FRs of the PDS. Management estimated this cost to be about one-half of the current assembly (direct labor) time per aircraft. To determine the cost of not achieving the FRs, the three most recent aircrafts to complete production were used as a baseline.

Accurately quantifying the impact of each PDS requirement not being met was difficult. From program metrics and data available, the following PDS requirements and solutions were estimated.

FR-111: Design products that meet program requirements

PS-111: Product Design Process

FR-Q1: Manufacture products within engineering requirements

PS-Q1: Elimination of assignable causes of variation (i.e., nonconformance work)

FR-P11: Ensure availability of relevant production information

PS-P11: Capable and reliable information system (i.e., unavailable, late, incomplete, inadequate, or unclear work instructions)

FR-P12: Ensure tools and supplies are available

PS-P12: Processes to ensure adequate supplies

FR-P132: Ensure availability of workers

PS-P132: Attendance policy enforcement (i.e., “labor loss”—excessive, insufficient or untrained workforce compared to requirements)

FR-P15: Ensure material available even though fallout exists

PS-P15: Standard material replenishment approach (i.e., part shortages)

Figure 8 shows the PDS with the quantified FR–PS pairs. The data collected are based on a per aircraft basis. Direct labor hours are defined as touch labor time; while indirect labor hours combined hourly support (noncontact labor time) and salaried employee time that is waste as a result of the defined functional requirement (FR) not being achieved as illustrated in the product delivery system (PDS) map. The PDS map is an extension of the manufacturing system design decomposition (MSDD) [42].

Direct labor cost per plane was estimated for each of the above requirements while indirect (nonassembly) cost per plane was only estimated for FR111, FR-Q1, FR-P12, and FR-P15. Total program cost was calculated by summing the direct and indirect costs.

Figure 9 displays the total labor hours per plane incurred from not fully achieving the six FRs analyzed, not accounting for path dependency.

The previous bar chart (Fig. 9) is then modified according to the degree of the path dependency indicated in Eq. (9) (see Fig. 3). Consideration of the path dependency in the system design identifies and more accurately estimates the allowable investment in each of the PSs from the costs incurred from not fully achieving specific FRs.

For example, as shown in Fig. 10, not fully implementing the engineering PS (PS-111) affects not only the achievement of its direct FR (FR-111) but also has significant effects on the achievement of quality (FR-Q1) and tooling (FR-P12) requirements. Figure 11 shows the summation of each PS's effect on its direct FR and its path-dependent FRs (i.e., depicted by summing the elements of each column in the design matrix [A]).

Accounting for path dependency yielded a more accurate estimate of the allowable investment in each of the PSs. For example, the allowable investment in engineering, PS-111, increased 55% over PS-111's previous value as shown in Fig. 9.

The PDS represents a system design in its entirety. Every FR must be achieved for the design to be complete. However, given limited resources, the knowledge of the path-dependent relationships provides a scientific basis for resource allocation.

This paper uses CSD, a systems engineering methodology, to sustain manufacturing systems in the context of enterprise and customer requirements. The approach is that to sustain a manufacturing system, the managers and leaders of an enterprise must invest in the resources to achieve all of the FRs of the system design. CSD defines the use of performance metrics and investment criteria to support a manufacturing system and provides a systems engineering-based approach that enables continuous improvement and strategic adaptability to change. A case study illustrated the use of the CSD methodology to allocate resources based on the cost of not achieving system FRs so that management can justify the resource requirements that are necessary to sustain a system design.

The co-authorship by Zhuming Bi was partially supported by the Program of Foshan Innovation Team of Science and Technology (Grant No. 2015IT100072). Special thanks go to Lockheed Martin Aeronautics Company, Dr. Don Kinard, LM Senior Fellow, and Mr. Frank Dougherty, LM VP for Aeronautics Manufacturing (Retired), for funding this analysis and research. The authors are pleased that the use of the Product Delivery System Map continues to be used by various LM projects to this day.