Tugas Kensis - Managing A Concurrent Engineering Environment.docx

MANAGING A CONCURRENT ENGINEERING ENVIRONMENT: TOOLS AND TECHNIQUES Many different tools and techniques have been developed for managing concurrent engineering initiatives in specific domains and/or films. However, nearly all of these methods exhibit the features of a structured process modeling language and techniques for evaluating the performance of a concurrent engineering environment. In this section we outline some useful enterprise modeling methodologies that have been used to study concurrent engineering systems. In addition, a product life-cycle-oriented risk assessment strategy is presented for managing concurrent engineering projects. 1. Methodologies for Modeling Concurrent Engineering Process In addition to being an essential tool for building concurrent engineering environments process models are also useful for managing and monitoring concurrent engineering projects. Many methodologies exist for modeling enterprises. Although the methods vary in scopes, appearance, and theoretical foundation, they all provide insight to the problem of concurrent engineering process model development. This section briefly describes several of the existing methodologies. 1.1 CIM-OSA Computer Integrated Manufacturing-Open Systems Architecture (CIM-OSA) is the subject of ongoing development by the ESPRIT Consortium AMICE. The methodology facilitates total enterprise modeling through a model construction process that includes enterprise implementation description. Four enterprise views, or perspectives, are considered: function, information, resource, and organization. Within each view, generic building blocks describe the functions, information, resources in the system. Relations between building blocks define the total enterprise (Beekman, 1989). CIM-OSA recognizes the functional, information, resource, and organizational perspectives that must be considered explicitly in modeling concurrent engineering environments. Furthermore, abstraction concepts such as encapsulation, classification, and inheritance are supported. 1.2 EXPRESS In 1980 ISO TC184/SC4/WG5 initiated work on EXPRESS and Version 1.0 was approved in 1991. The PDES consortium uses EXPRESS systematically in its work on STEP. A graphical representation of the language is available as EXPRESS-G. The methodology provides a syntax for defining classes of entities (which may be information, resources, material, products, etc.) that support abstraction. Dynamic behavior, however, cannot be modeled. Although not as explicit as CIM-OSA, EXPRESS can capture the functional, information, resource, and organizational perspectives of concurrent engineering environments (European Committee for Standardization, 1994). 1.3 GRAI Method The GRAI method was developed by the GRAI Laboratory in the early 1980s and has been used internationally in manufacturing applications (Doumeingts et al., 1987). The GRAI method is built around a conceptual reference model that is based on the theories of complex system, hierarchical system, organization system, and discrete activities theory. The manufacturing system is structured in three subsystems: a physical system, an information system, and a decision system. The GRAI formalism

focuses on the decision subsystem and relies on other methods, such as IDEF0 and entity relationship attribute (ERA), to model the physical and information systems. The GRAI formalism is supported by two graphical representations: the GRAI grid, and the GRAI net. Although the GRAI method explicitly focuses on decomposition of the organizational perspective, it does not, in itself, cover the functional, information, and resource perspectives. Through decomposition, the method supports encapsulation. However, classification and inheritance are nor supported. 1.4 IDEF Methods As discussed in Section 9.3.2.1, development of the IDEF methods began with the Air Force program for ICAM and continued as part of the Air Force IICE program. Although IDEF0 and IDEF3 are the most popular, additional IDEF methods have been and continue to be develop. The IDEF1x model is used to semantically model the relationships between various pieces of data. The basic constructs of an IDEF1x model include entities, attributes, and relationships (Mayer, 1990). The IDEF4 methodology provides syntax and semantics for capturing the thought process that is required to develop modular, maintainable, and reusable applications programmed in object-oriented languages such as C++, Object Pascal, Common Lisp Object System (CLOS), Smalltalk (Mayer et al., 1992b). The dynamic behavior of a system ca be captured using IDEF2. Methods for modeling domain ontologies (IDEF5) and defining the motives that drive the decision-making process (IDEF6) are in development. As a whole, the IDEF family of methods facilitates model construction for a variety of architectural perspectives. 1.5 IEM Integrated Enterprise Modeling (IEM) is a public domain methodology develop by IPK Berlin (European Committee for Standardization, 1994). Unlike the previous methods (with the exception of IDEF4), IEM is designed around the object-oriented paradigm. Objects in manufacturing and design systems are describe by data and functions that change the objects. Objects are distinguished by purpose into three classes: products, orders, and resources. All real objects in the manufacturing environment belong to one of the three IEM classes and subclasses. A generic activity model is defined for operating on objects. The object-oriented paradigm allows for the simultaneous modeling of the functional and information perspectives through a single construct class. Although not explicitly considered in IEM, the organizational perspective can be added and integrated using the class concept. This methodology illustrate the robust, generic modeling capabilities provided by the object-oriented paradigm that are useful for modeling the concurrent engineering environment. 1.6 PSL/PSA Problem Statement Language/Problem Statement Analyzer (PSL/PSA) was commercially developed by META Systems (European Committee for Standardization, 1994). The PSL component is a language that can be used to describe information systems in terms of objects, properties, and relationships. As with IDEF1x, PSL/PSA is based on the concepts of relational database theory. Formal and graphical representations are provided and reports can be generated from the commercially

available software. The relational approach to modeling provided by PSL/PSA is less desirable in comparison to object-oriented methodologies that are available. 1.7 SSADM Structured Systems Analysis and Design Method (SSADM) is the standard method of systems analysis and design used by the UK government. SSADM was developed by the Central Computer and Telecommunications Agency in the early 1980s. The method focuses on analysis of business requirements, design, and specification of application data bases and software. A project is broken down into modules that contain activities that must be completed to deliver the product. Each step has a list of tasks, inputs, and outputs. SSADM has modules for feasibility study, requirements analysis, requirements specification, logical system specification, and physical design (Ashworth, 1988). The clear focus of SSADM is on the information perspective. Although many information modeling techniques are incorporated (i.e., data flow modeling, entity event modeling, and relational data analysis), the method does not employ the object-oriented paradigm. 1.8 OOMIS The Object-Oriented Modeling Methodology for Manufacturing Information Systems (OOMIS) consists of two phases, an analysis phase and a design phase (Kim et al., 1993). The first task of the analysis phase is to decompose the manufacturing functions into component functions using an approach similar to IDEF0. After constructing a functional model, function tables, data tables, and operation tables are generated. In the design phase, the object-oriented paradigm is used to translate the function tables, data tables, and operation tables into an integrated information model. Classes consisting of an identifier, attributes, and methods are defined for components of the manufacturing system. Two specific class types are used, function class and entity class. Semantic design is facilitated by relationship diagrams. OOMIS displays many features that are desirable for modeling the concurrent engineering environment. Unlike other methods that treat the functional and information perspectives independently (i.e., IDEF), the object-oriented paradigm is employed to form an integrated model. In fact, the information perspective is derived directly from the functional model. 2. Risk Assessment in Concurrent Engineering This section presents a strategy for risk assessment in concurrent engineering environments. The proposed strategy is based on the premise that a holistic model of the product life cycle can be used to evaluate the design of any product in the domain of the firm. Therefore, the product can be defined in the context of the activities that must be performed to result in a successful product, rather than traditional methods of modeling based on the design artifact. To capture the necessary level of detail in a model of the product life cycle, a comprehensive modeling methodology must be employed. The IDEF family of methods has been adopted for this purpose. Once the model has been developed, it can be used repeatedly to evaluate the design of different products. Customer requirements provide an initial summary of the activities that must be performed; however, the entire design scenario (and ensuing path through the product life cycle) may seldom, if ever, be realized. Therefore, the project management challenge is that of determining the remaining activities in a project plan that result in a successful design. The determination of a final design scenario is based on a variety of concurrent engineering risk factors that impact the remainder of the product life cycle. As a result, the overall risk, considering the

perspectives of many different functional areas, can be mitigated. Risk assessment is a process that attempts to answer three questions: (1) What can go wrong? (2) What is the likelihood that it will go wrong? (3) What are the consequences? (See Chapter 3.) Based on these questions, Equation (9.1) is a quantitative definition of risk, where R is risk, S is a scenario of events that leads to a problem, P is the likelihood of the scenario, and C is the consequence of the scenario: R = {S,P,C}

(9.1)

A scenario captures all of the activities in the product life cycle, including everything from design to disposal. The probability of the scenario is determined by the likelihood that the activities in the scenario do not accomplish the objectives of the product. Adverse consequences for a scenario, or product/process design (e.g., violated due dates, low potential recyclability), can result from activities throughout the product life cycle. Risk R is calculated by Equation (9.2), where Pk is the probability of scenario k, Ck is the consequence of scenario k: R = ∑𝐾 𝑘=1(𝑃𝑘 𝑥 𝐶𝑘)

(9.2)

The life-cycle-oriented risk assessment procedure is summarized below. In sections 9.4.2.1-9.4.2.4 we discuss each step in greater detail. Risk Assessment Procedure 1. Identify scenarios by determining all possible path-sets in the IDEF3 model of the product life cycle. 2. Estimate the probability of each scenario using a formal weighting scheme. 3. Determine the consequences of each scenario based on the relevant performance measures and domain experts' perceptions of risk. 4. Calculate risk using Equation (9.2). 2. 1 Identifying Product Life-Cycle Scenario The concept of path-sets in IDEF3 models is used to identify scenarios. A path-set Pk = I, ... ,K) in an IDEF3 model is a set of all UOBs that define a path from source to sink in the model. The path-set is determined by junctions in the model and only one path set is taken for each execution of the model. Thus, a path-set identifies a scenario in the product life cycle. Due to the semantics of IDEF3 junction boxes, path-sets are difficult to identify by inspection, even in relatively simple models. The IDEF3 pathset algorithm (Larson and Kusiak, 1996) uses an activity-activity precedence matrix to represent the model and determine all possible path sets. Example 9.7. Identifying Product Life-cycle Scenarios. This example is based on a portion of the product life cycle corresponding to the manufacturing process at an electronics manufacturer. Figure 9.27 shows a simplified version of the IDEF3 model for the process with 27 DaBs and various junction boxes. The IDEF3 path-set algorithm is applied to obtain the path sets listed in Table 9.9. As shown in this example, for even small models, it is not feasible to determine all possible path-sets by inspection. This example illustrates the large number of scenarios defined for even one phase of the product life cycle. Thus, it is obvious that as the design, mailUfacturing, sales, service, and disposal functions are aggregated, the model becomes extremely complex and many possible product life-cycle scenarios must

be evaluated (one corresponding to each path-set). As customer requirements become known for new products, perhaps through the use of QFD (Hauser and Clausing, 1988), infeasible scenarios can be eliminated from the product life cycle. 2. 2 Weighting and Aggregating Scenario Probabilities Recall that the probability of a scenario is the likelihood that the UOBs in the path-set are not successfully completed. Figure 9.27 The first step in calculating scenario probability is to determine the risk factors that will be considered and weight them accordingly. This information can be obtained by asking domain experts the following questions: (I) What key characteristics of products and processes are important to complete a successful design? (2) How can these characteristics be measured, monitored, and evaluated? The key characteristics provide valuable information about risk factors early in the design process. For example, on-time delivery to the customer may be cited as a key characteristic. Therefore, schedule risk may be identified as a risk factor. A possible measure of this characteristic may be the percent on-time delivery for similar products. After collecting this information, a hierarchy similar to that shown in Figure 9.28 can be constructed to apply weights to the relevant risk factors. A method such as the AHP can be used for weighting and aggregating risk factors. The AHP is a method for multicriteria decision making proposed by Saaty (1981). It is based on the premise that if a complex problem is decomposed into a hierarchy, pairwise comparisons can be made between the attributes of the problem to determine the best alternative. The goal (objective) is placed at the top of the hierarchy. The next level of the hierarchy contains attributes, or criteria, which contribute to the quality of the decisions. Each attribute can be decomposed into more detailed attributes, with the lowest level of the hierarchy containing the decision alternatives. After the hierarchical network is constructed, priorities of the elements are determined at each level of the decision hierarchy, and the elementary priorities are synthesized to rank the decision alternatives. The hierarchy can focus the analysis on specific risk factors that are relevant to the overall goal of achieving a successful design. Domain experts can then estimate the likelihood that adverse effects will result from a risk factor. For example, failure rates of machines can be used to estimate the probability that a production schedule will not be met. In practice, many factors can contribute to the probability of adverse effects (i.e., the probability a scenario results in a flawed design). Ongoing research is exploring additional methods, such as fuzzy logic, for obtaining accurate measures for scenario probability (Larson and Kusiak, 1996). Table 9.9 Path-Sets for the IDEF3 Model in Figure 9.27 2. 3 Identifying and Evaluating Consequences of Scenario Figure 9.28 Hierarchy for calculating risk factor weights Table 9.10 Consequences of Concurrent Engineering Risk Factors Risk Factor Requirements risk Technical risk

Consequences Loss of customer base Due date violation Poor quality

Measures of Consequence Number of customer complaints Days past deadline Number of rejects Rework cost

Schedule risk

Additional resource requirement Due date violation

Cost risk

Higher product cost

Network risk

Due date violation Information loss Additional design iterations Due date violation Additional resource requirement Due date violation Additional resource requirement

Redesign risk

Resource risk

Environmental risk

Pollution Negative public perception

Day past deadline Personnel cost Overhead cost Sale price of product Loss of market share Capital cost Days past deadline Personnel cost Overhead cost Days past deadline Capital cost Personnel cost Overhead cost Days past deadline Cleanup expenses Product disposal costs

The consequences of a scenario are the adverse effects realized by failing to successfully complete the UOBs in the corresponding path-set. Table 9.10 lists some common consequences of various concurrent engineering risk factors. Obviously, each of these consequences results in higher product development cost. An aggregate measure of this cost is typically domain dependent and reflects management objectives and customer concerns. Once again, the relationships between a risk factor, consequences, and alternative design scenarios can be captured in a hierarchy, as shown in Figure 9.29. The overall goal is to mitigate risks. The consequences on the second level can be evaluated to determine those that are most important to achieving that goal. The importance of each scenario in contributing to the consequences is evaluated at the lowest level. The scenarios at the lowest level correspond to product life-cycle scenarios, such as those listed in Table 9.9. The weights obtained at the second level in Figure 9.29 can be used to derive a cost function for a given risk factor. Formal procedures for determining consequences must address the issue of building valid hierarchies, including protocols for conducting group meetings (Saaty, 1981; Larson and Kusiak, 1996). 2. 4 Calculating Risk Figure 9.29 Hierarchy for mitigating risks Desirable product life-cycle scenarios can be identified using the AHP and hierarchies such as the one shown in Figure 9.29. However, it is also informative to calculate a value for process risk and compare it to other scenarios. Recall that if the scenario probability can be estimated and a cost function is derived for the consequences of a scenario, process risk is calculated using Equation (9.2). All activities in the life-cycle-oriented risk assessment procedure are performed by concurrent engineering teams (see Section 9.3.1.1). This allows a broad range offunctional perspectives to contribute to the risk assessment process. In fact, any successful life-cycle risk assessment program must be constructed around the concurrent engineering design team concept. Furthermore, risk assessment must serve as a key component to managing the concurrent engineering environment.