Using the Design Structure Matrix (DSM) for Process Integration

The new standards advocate integrated engineering processes. A process is a kind of system. As such, it derives its added value from the relationships among its parts (e.g., activities). For a group of activities to be truly integrated (versus merely aggregated), their interfaces must be well defined. In engineering processes, these interfaces usually indicate a flow of information. Engineering processes are extremely complex because of the large number of interfaces, as many types of information flow to many destinations. This paper reviews a powerful technique, the design structure matrix (DSM), for representing and analyzing complex processes. The DSM is extended to account for external inputs and outputs, providing the basis for process puzzle pieces that can be assembled to form large, integrated processes. INTRODUCTION Emerging standards for engineering, design, and product development processes such as CMMi, EIA/IS 731, ISO 15288, etc. advocate the inclusion of a number of “good practices.” Essentially, these practices are activities that should be part of any development process so that it can be capable, mature, repeatable, etc.—with the implication that such processes provide the maximum value to their customers and users. Unfortunately, processes for the development of large, complex systems are already complex, and the inclusion of additional activities does not make them any simpler. One of the major problems in complex system development projects is the difficulty coordinating the contributions of a number of activities, such that each of these contributions comes at just the right time. In product development, many of the contributions come in the form of information that is consumed, transformed, and supplied by activities. The value of the process is compromised when information is “out of sync,” forcing those executing activities to make assumptions in the absence of real data [3, 4]. This problem is exacerbated as more activities and contributions must be managed. No one can keep track of everything. We need better tools that will give us visibility into these situations, highlight problems, suggest solutions, and be able to handle increasing complexity. A classic means to address and reduce complexity is through modeling. A model is an abstract representation of reality that is built, analyzed, and manipulated to increase understanding of that reality. A good model is helpful for testing hypotheses about the effects of certain actions in the real world, where such actions would be too disruptive or costly to try in the real situation. Here, we are interested in models that will help us represent, understand, manage, and improve complex processes. Such models would also facilitate process integration. Process modeling, like many other types of system modeling, is often approached through process decomposition into simpler elements. But a complex process is more than just a grouping of activities. It exists for a purpose—to produce something. Especially in product development context s, that something typically requires the activities to collaborate, not simply to make a unilateral contribution. Process complexity is a function of (1) the number of elements, (2) the individual complexity of each of those elements, (3) the number of relationships between the elements, and (4) the individual complexity of each of those relationships. Rechtin [7] reminds us that relationships among elements are what give systems their added value, and that the greatest leverage in systems architecting is at the interfaces. This is no less true for processes. Hence, a good process model must account for the interfaces between its activities. Unfortunately, what often passes for a process model in industry fails to say much about the relationships between activities, 1 Of course, decomposition presents the danger of incorrect abstraction—failing to represent the characteristics of the process that provide its full value and capability.

Récupéré en direct depuis OpenAlex et désinversé. Les résumés ne sont pas conservés dans cette base de données : les index inversés représentent 8,6 Go des 9,3 Go de texte de la base, et le serveur dispose de 13 Go libres.