Reengineering of design and manufacturing processes

16
Pergamon Computers ind. Engng Vol. 26, No. 3, pp. 521-536, 1994 Copyright © 1994 Elsevier Science Ltd 0360-8352(93)E0023-2 Printed in Great Britain. All rights reserved 0360-8352/94 $7.00+ 0.00 REENGINEERING OF DESIGN AND MANUFACTURING PROCESSES ANDREW KUSIAK, T. NICK LARSON and JUITE (RAY) WANG Intelligent Systems Laboratory, Department of Industrial Engineering, The University of Iowa, Iowa City, IA 52242-1527, U.S.A. (Received for publication 31 December 1993) Al~tract--The developmentof IDEF tools for modeling and analysis of processeshas been motivated by the desire to increaseproductivityby improvingcommunicationand structure of manufacturing systems. Constructing an IDEF model is only one component of a comprehensive process modeling effort. Representing IDEF models as process graphs, performing observationalmodel analysis, and analysis of IDEF model structure are issues addressed in this paper. The paper includes a review of current approaches to IDEF modeling in industry, as well as techniques for analysis of IDEF models. The fundamentals of IDEF0 and IDEF3 are discussed,however,the emphasis of the paper is on model analysis and reengineering design and manufacturing processes. An algorithm for model analysis is presented. 1. INTRODUCTION The origin of modeling and analysis of information systems dates to the late 1960s and early 1970s. A graphical notation for representing the processes which transform data was needed to assist in the development of a design architecture. DeMarco [1] introduced the term structured analysis, as well as a set of symbols and a methodology for creating information flow models. The data flow diagram (DFD) models information flow and transformation on varying levels of detail. At level 0, the DFD represents the entire system. Additional information may be incorporated on level 1, level 2, and so on, as subfunctions of the overall system. As deficiencies in the diagramming approach became apparent, variations and extensions of structured analysis were proposed by Page-Jones [2], Gane and Sarson [3], Ward and Mellor [4], Hatley and Pirbhai [5], and many others. Among the contributions, a notation for modeling real-time systems by capturing control flow and control processing information was added to structured analysis. A similar effort was underway at Softech, Inc., where Ross and Schoman [6] were researching structured functional analysis. From this effort, the Structured Analysis and Design Technique (SADT) was developed. SADT is a graphic language which "provides a limited set of primitive constructs from which analysts and designers can compose orderly structures of any required size" [6]. The notation consists of boxes and arrows which represent system components and interfaces, respectively. SADT models capture multiple levels of detail in a hierarchical manner, with the top level being a general representation of the system. For a complete description of structured analysis (SA), the graphical language component of the SADT methodology, see Ref. [7]. Ross [8] presented numerous applications, extensions and enhancements of SADT. During the 1970s, ITT Europe used SADT to design telephonic switching systems and train personnel. Other commercial applications of the methodology included financial and transaction models, budget construction and tracking cycles, security systems, and curriculum development in education [8]. The power of SADT as a communication and analysis tool was recognized in 1978 by the United States Air Force that selected it as the language to support the Integrated Computer Aided Manufacturing (ICAM) program. SADT activity modeling was adopted by the ICAM program and revised by SofTech, Inc. to develop the ICAM Definition Methodology (IDEF0). Ross [8] states that "thousands of people from hundreds of organizations working on more than one hundred major projects" proceeded to use the methodology for system definition and design, as well as project management. 521

Transcript of Reengineering of design and manufacturing processes

Page 1: Reengineering of design and manufacturing processes

Pergamon Computers ind. Engng Vol. 26, No. 3, pp. 521-536, 1994

Copyright © 1994 Elsevier Science Ltd 0360-8352(93)E0023-2 Printed in Great Britain. All rights reserved

0360-8352/94 $7.00+ 0.00

REENGINEERING OF DESIGN AND MANUFACTURING PROCESSES

ANDREW KUSIAK, T. NICK LARSON and JUITE (RAY) WANG Intelligent Systems Laboratory, Department of Industrial Engineering, The University of Iowa,

Iowa City, IA 52242-1527, U.S.A.

(Received for publication 31 December 1993)

Al~tract--The development of IDEF tools for modeling and analysis of processes has been motivated by the desire to increase productivity by improving communication and structure of manufacturing systems. Constructing an IDEF model is only one component of a comprehensive process modeling effort. Representing IDEF models as process graphs, performing observational model analysis, and analysis of IDEF model structure are issues addressed in this paper. The paper includes a review of current approaches to IDEF modeling in industry, as well as techniques for analysis of IDEF models. The fundamentals of IDEF0 and IDEF3 are discussed, however, the emphasis of the paper is on model analysis and reengineering design and manufacturing processes. An algorithm for model analysis is presented.

1. INTRODUCTION

The origin of modeling and analysis of information systems dates to the late 1960s and early 1970s. A graphical notation for representing the processes which transform data was needed to assist in the development of a design architecture. DeMarco [1] introduced the term structured analysis, as well as a set of symbols and a methodology for creating information flow models. The data flow diagram (DFD) models information flow and transformation on varying levels of detail. At level 0, the D F D represents the entire system. Additional information may be incorporated on level 1, level 2, and so on, as subfunctions of the overall system.

As deficiencies in the diagramming approach became apparent, variations and extensions of structured analysis were proposed by Page-Jones [2], Gane and Sarson [3], Ward and Mellor [4], Hatley and Pirbhai [5], and many others. Among the contributions, a notation for modeling real-time systems by capturing control flow and control processing information was added to structured analysis.

A similar effort was underway at Softech, Inc., where Ross and Schoman [6] were researching structured functional analysis. From this effort, the Structured Analysis and Design Technique (SADT) was developed. SADT is a graphic language which "provides a limited set of primitive constructs from which analysts and designers can compose orderly structures of any required size" [6]. The notation consists of boxes and arrows which represent system components and interfaces, respectively. SADT models capture multiple levels of detail in a hierarchical manner, with the top level being a general representation of the system. For a complete description of structured analysis (SA), the graphical language component of the SADT methodology, see Ref. [7].

Ross [8] presented numerous applications, extensions and enhancements of SADT. During the 1970s, ITT Europe used SADT to design telephonic switching systems and train personnel. Other commercial applications of the methodology included financial and transaction models, budget construction and tracking cycles, security systems, and curriculum development in education [8].

The power of SADT as a communication and analysis tool was recognized in 1978 by the United States Air Force that selected it as the language to support the Integrated Computer Aided Manufacturing (ICAM) program. SADT activity modeling was adopted by the ICAM program and revised by SofTech, Inc. to develop the ICAM Definition Methodology (IDEF0). Ross [8] states that "thousands of people from hundreds of organizations working on more than one hundred major projects" proceeded to use the methodology for system definition and design, as well as project management.

521

Page 2: Reengineering of design and manufacturing processes

522 ANDREW KUSIAK et al.

IDEF0 introduced manufacturing to techniques that were developed for computer system and software engineering applications. Additional IDEF techniques were developed for information analysis (IDEF1), dynamic analysis (IDEF2), and process modeling (IDEF3).

The IDEF tools have been widely discussed in the literature, however, much of the work published discusses the basic concepts and applications. Colquhoun et al. [9] presented a detailed review of IDEF0 and cited several issues that had received little attention in the literature. Broader aspects of IDEF modeling, such as information collection and model analysis are seldom discussed. As a result, many authors have recognized the substantial investment in resources and little use of the final product as drawbacks to IDEF modeling. Busby and Williams [10] provided a thorough discussion of limitations of process modeling; such as, a lack of quantitative information, subjectiveness of models, difficulty of expressing habitual and intuitive processes, and obviousness of findings that result from a model.

Constructing an IDEF model is only one component of a comprehensive process modeling effort. Representing IDEF models as process graphs, performing observational model analysis, and analysis of IDEF model structure are issues addressed in this paper. The fundamentals of IDEF0 and IDEF3 are discussed, however, the emphasis of the paper is on model analysis and reengineering design and manufacturing processes. A triangularization algorithm extended from Kusiak e t al. [11] is presented for process model analysis.

2. IDEF0 AND IDEF3

IDEF0 was developed for modeling a wide variety of systems which use hardware, software, and people to perform activities [12]. An IDEF0 model consists of three components, diagrams, text, and a glossary, all cross-referenced to each other. The box and arrow diagrams are the major components of the model. In a diagram, a box represents a function and an arrow represents an interface. A box is assigned an active verb phrase to represent the function. An interface may be an input, an output, a control, or a mechanism, and is assigned a descriptive noun phrase. Inputs (I) enter the box from the left, are transformed by the function, and exit the box to the right as an output (O). A control (C) enters the top of the box and influences or determines the function performed. A mechanism (M) is a tool or resource which performs the function. The interfaces are generally referred to as the ICOMs (see Fig. 1).

Each diagram has between 2 and 6 function boxes placed on a diagonal. The boxes each have a specific node number and are connected by all relevant interfaces. Each box on the diagram may be decomposed into a lower level of detail. This feature restricts the amount of information that may be contained in the model on a single level. The resulting diagrams form a hierarchy of information which is summarized in a node tree. Figure 2 illustrates the decomposition principle of an IDEF0 activity model.

IDEF0 provides a structured representation of the functions, information, and objects which are interrelated in a manufacturing system. IDEF3 was created specifically to model the sequence of

Control (C)

Function

Mechanism (M) Fig. 1. IDEFO function box and interface arrows.

Page 3: Reengineering of design and manufacturing processes

Design and manufacturing processes

I I

Top level

Level 1

I

Level 2

Fig. 2, IDEF0 model decomposition.

523

activities performed in a manufacturing system. An IDEF3 model enables an expert to communi- cate the process flow of a system through defining a sequence of activities and the relationships between those activities. There are two basic components of the IDEF3 process description language, the process flow description and the object state transition network description. The two components are cross-referenced to build IDEF3 diagrams [13].

The IDEF3 process flow description is made up of units of behavior (UOBs), links, and junction boxes. A UOB represents a function or activity occurring in the process. For example, assemble parts, perform inspection, or evaluate proposal are all activities which may be represented as UOBs in a process model. Relationships between UOBs are modeled with three types of links, precedence links, relational links, and object flow links. Precedence links express simple temporal precedence between UOBs. Relational links highlight the existence of a relationship between two or more UOBs, however, no temporal constraint is implied. Object flow links provide a mechanism for capturing object related constraints between UOBs and carry the same temporal semantics as a precedence link. The logic of branching within a process is modeled using junctions. Several classifications are used to define junction boxes. Junctions are classified according to logical semantics as and (&), or (O), and exclusive or (X). Multiple process paths are classified as fan-in or fan-out corresponding to converging and diverging paths, respectively. The relative timing of process paths that converge or diverge at a junction are classified as synchronous or asynchronous. An example of an IDEF3 process flow diagram is shown in Fig. 3 [13].

Object state transition network (OSTN) diagrams are used in IDEF3 to model object state changes relative to the process flow description. The basic elements of OSTN diagrams are nodes (circles) and arcs. Each object in the IDEF3 model may have a corresponding OSTN diagram. Nodes in the diagram represent different states of the object. Arcs represent possible transitions

Page 4: Reengineering of design and manufacturing processes

524

Evaluate

ANDREW KUS1AK et al.

Reject ]

Negotiate

Accept

Aw'ad contract

Fig. 3. IDEF3 process flow diagram [13].

that the object can make between states. Each transition arc may have referents to scenarios, UOBs, or other OSTNs. An example of an OSTN is shown in Fig. 4 [13].

Both components of IDEF3 models, process flow descriptions and OSTN diagrams, feature additional capabilities for decomposition and elaboration. For a detailed description of the IDEF3 process description capture method see Mayer et al. [13].

3. OBSERVATIONAL ANALYSIS OF PROCESS MODELS

Due to the qualitative nature of process modeling, analysis is often based on observations. This section describes several rules for observational analysis that enable the analyst to identify areas in the model that reflect deficiencies in the actual system. The rules are applied to the IDEF0 and IDEF3 models and, in most cases, exploit the features of the two modeling languages.

3.1. Shorten the duration of activities

The ICOM structure of an IDEF0 model may be used to identify activities that can be shortened. The decomposition principle of IDEF0 allows the analyst to study the underlying process on many levels of detail. As the analyst explores the decomposition, controls and mechanisms are recognized as constraints for each activity. Therefore, methods of relaxing control and mechanism constraints must be explored. The analyst should consider modifying mechanisms. For example, manually operated mechanisms may be replaced by automation. Similarly, the analyst should attempt to eliminate or simplify controls. Typically, a control is a piece of information that is required to perform the activity. The authors have discovered that most systems are too information intensive

[l uo

[ Identify key I concepts

I ~/!

@ J _ I

Explore key concep~

and validate I c°nceP6/1 ]

Fig. 4. IDEF30STN diagram [13].

Page 5: Reengineering of design and manufacturing processes

Design and manufacturing processes 525

(see Section 4.2). Reducing the amount of information that is required to perform the activity will often reduce the duration and simplify the process.

3.2. Eliminate redundant activities

Figure 5 illustrates the principle of eliminating redundant activities in the context of an IDEF0 model. Redundant activities often exist in inspection and partially automated processes. The analyst should also focus on areas of the model that are separated by physical and/or logical boundaries in the actual system. At these points, material and/or information is passed between departments, personnel, teams, and so on. The authors have discovered that the likelihood of redundant activities is greater at these points.

3.3. Partition an activity

In many cases, a single activity may be partitioned into two concurrent activities, each with a shorter duration. If this is possible, the overall duration of the process may be reduced. For example, if a random sample is to be obtained from a batch of parts for two types of testing, the testing activity may be split into two concurrent activities, one for each test. Figure 6 illustrates the concept of partitioning an activity in an IDEF3 model.

3.4. Combine two serial activities

Combining two serial activities may shorten the overall duration of the process. This approach works particularly well in systems with high levels of material and/or information handling. By combining activities, work performed in two different areas may be performed in one, thus, eliminating the material and/or information handling. Figure 7 illustrates the principle of combining serial activities in an IDEF0 model. Note the difference between Fig. 5 and Fig. 7; in

I1 .J -I

Activity 1

o ,

~ ~ Activity 2

Ca)

I1 J "'I Activity 1 ?.

(b)

Fig. 5. Result of eliminating a redundant activity.

Page 6: Reengineering of design and manufacturing processes

526

Activity 1

I

ANDREW KUSIAK et al.

Y

Activity 1

I

(a)

Activity 2'

I

Activity 2"

I

(b)

Fig. 6. Result of partitioning an activity.

I1 .J Activity 1

01

(a)

Activity 2

I1

c1~ J ...-1 Activity 1'

Ca) Fig. 7. Result of combining two activities.

Page 7: Reengineering of design and manufacturing processes

Design and manufacturing processes 527

Fig. 5, Activity 2 and its associated ICOMs are eliminated from the process, however, in Fig. 7, activity l ' and its associated ICOMs replace activities l and 2.

3.5. Eliminate cycles

In Section 4, a formal method of identifying cycles in an IDEF model is presented. However, many of the shorter cycles in a model may become apparent during the observational analysis. In order to shorten the overall duration of the process, it is necessary to eliminate unnecessary cycles. Figure 8 illustrates the result of eliminating a cycle in an IDEF3 model. Notice that an activity is also eliminated by eliminating the cycle.

4. ANALYSIS OF IDEF MODEL STRUCTURE

The most frequently recognized shortcoming of process modeling may be the lack of use and/or incomplete analysis of models. Due to the qualitative nature of models, mathematical techniques are difficult to apply. This section discusses an algorithm for graph analysis that has been successfully applied to IDEF models. An IDEF0 or IDEF3 diagram can be represented as a process graph and corresponding incidence matrix. Elements of the matrix may then be manipulated using the concepts of graph theory to identify the underlying structure of the IDEF model.

4. I. A modified triangularization algorithm

Kusiak et al. [11] presented the triangularization algorithm as a tool for organizing design activities. The algorithm identifies groups of activities and arranges them concurrently. An activity-activity incidence matrix and the corresponding directed graph is used to represent the relationships between activities in a process. A non-empty element in an incidence matrix represents a relationship between the corresponding activities. The objective of the algorithm is to order rows and columns of the incidence matrix into a lower triangular form. A non-empty element in the upper triangular matrix verifies the existence of a cycle in the process. The algorithm is very effective at identifying the structure of IDEF0 and IDEF3 models.

The algorithm extended from Kusiak et al. [11] is developed for the analysis of IDEF0 and IDEF3 models. The IDEF model may be represented as a process graph and corresponding activity-activity incidence matrix. The triangularized activity-activity incidence matrix identifies cycles and concurrent activities.

q

Activity 3

I

(a)

. . • Acfivityl [ --.J Activity2

i I -I i 0')

Fig. 8. Result of eliminating a cycle.

Page 8: Reengineering of design and manufacturing processes

528 ANDREW KUSIAK et al.

To present the algorithm, a terminology is introduced. An activity is called an origin activity (OA) if there are no other activities preceding it. The OA activities can be easily identified in the incidence matrix. I f the i-th row of the incidence matrix has only one non-empty element (a diagonal element), then v~ is an OA. In a digraph with no OA s, there exists at least one cycle [11].

The modified triangularization algorithm Input. Incidence matrix A = [a~j], ×, Output. L = {L(i)lset of activities in level number i}, C = {C0')lset of coupled activities in group

number j }

Step 1. Set level number i ~ l , group number j ~ l ; and L(i)~-q~, C(j)~(a, OA ~c~, and E ~ b , where

OA = {tit is an activity without predecessor (an origin activity)}, E = {trt is an activity involved in a cycle}.

Set activity level number O ( k ) ~ l , for k = 1 . . . . . n. Step 2. Check if the incidence matrix A is empty. I f A is empty, then stop. Step 3. Identify origin activities

I f OA ~ ~b, then for all t E OA, do begin

if t ~ C, then L(O(t ) )*--L(O(t ) )wt; otherwise, L(i)*--L( i )ut; go to Step 4.

end I f OA = ~b, then go to Step 5.

Step 4. Delete from the incidence matrix A all entries associated with the activities in OA. For a l l t ~ O A , K = l . . . . . n, begin

if ak, = '*' , then set ak,~" and O ( k ) ~ i + 1; if ark = '*' , then set atk~---";

end if L(i ) ~ c~, then set i ~ i + 1 and L ( i ) ~ b ; OA ~c~ ; go to Step 2.

Step 5. Find a cycle E. Step 6. Merge the cycle E found.

L e t s ~ E a n d for a l l t ~ E a n d t C s begin

f o r i ~ - I to n begin

if as~ = '* ' then a,~ = '* ' and as~ = " # move predecessors of activity s to activity t

if a~s = '* ' then a~, = '* ' and a~ = " # move successors of activity s to activity t

end end if Cc~E = C(q) ~ c~, for some q, then C(q)*--C(q)uE; otherwise, set C ( j ) ~ E , j , -- j + 1, and C(j).--~b;

O ( C ( j ) ) ~ M a x {O(t)}; t~CO)

E~4~; go to Step 3.

Note that the O(k) records the level number of activity k. The level number of each activity is set to one at the beginning of the algorithm. Step 3 determines the set OA of origin activities. I f OA is not empty, then go to Step 4 and delete from matrix A the activities associated with the activities in OA. I f activity t is a successor of any of the activities in OA, then the level number

Page 9: Reengineering of design and manufacturing processes

Design and manufacturing processes 529

O(t) of that activity is set to the current level number plus one. The level number O(t) of each activity is always greater by one than the level number of its nearest predecessor. If OA is empty, then there must exist at least one cycle which is determined in Step 5. Tarjan's algorithm [14] is used to find cycles. In Step 6, the activities in the cycle found are merged with the existing set of coupled activities, provided that they have some activities in common; otherwise, a new set of coupled activities is created. Note that the level number for a set of coupled activities is the maximum level number of the activities in the set. This process continues until matrix A is empty.

The following example is used to demonstrate the algorithm. Consider the twelve design activities shown in Fig. 9 with the values of O(k) set to 1. The iterations of the algorithm are performed as follows.

Step I. Step 2. Step 3. Step 4.

Step 2. Step 3. Step 4.

Step 2. Step 3. Step 4.

Step 2. Step 3. Step 4.

Step 2. Step 3. Step 5. Step 6.

Step 3. Step 5. Step 6.

Step 3. Step 5.

Set i ~ l , j , , - 1 , L(1)<-q~, C(l),,--~b, OA*--gp, E~gp, and O(k)(-1 for k = 1 . . . . . 12. Since A 4: q~, go to Step 3. OA~{1,2}; since OA ~d? and {1,2}¢C, set L(1)~{1,2} and go to Step 4. Delete all entries associated with activities 1 and 2 from matrix A; set 0(3) = 0(6) -- 0(7) = 0(8) = O(10) = O(11) = O(12) = 2; since L(1) ~ ~b, set i<-2 and L(2)~t~; OA,,-qb; go to Step 2. Since A :~ 4, to to Step 3 (see Fig. 10a). OA <-{3}; since OA ~ c~ and {3} ¢ C, set L(2)~{3} and go to Step 4. Delete all entries associated with activity 3 from matrix A; set 0(4) = 0 ( 9 ) - - O ( 1 0 ) = O ( l l ) = 3; since L(2)4: q~, set i(-3 and L(3)~-q~; OA *--~b; go to Step 2. Since A ~ q~, go to Step 3. OA, -{ l l} ; since OA ~ ~ and {ll} ¢ C, set. L (3 )~{ l l } and go to Step 4. Delete all entries associated with activity 11 from A; set 0(5) = 0(7) = 0(8) = O(10) = 4; since L ( 3 ) ~ ~b, set i,,-4 and L(4)~q~; OA +--~b; go to Step 2. Since A :~ ~b, go to Step 3. OA o--{7}; since OA v~ d~ and {7} ¢ C, set L(4)~{7} and go to Step 4. Delete all entries associated with activity 7 from A; since L(4) ~ 4), set i<-5 and L(5)4-q~; OA ~q~; go to Step 2. Since A ~ ~b, go to Step 3 (see Fig. 10b). Since OA = 4), go to Step 5. Find a cycle (4, 8, 5, 4). Set E = {4, 5, 8} and go to Step 6 (see Fig. 10c). Since C n E = qS, C(1),,--{4, 5, 8}; set j , , -2 and C ( 2 ) ~ b ; O(C(1))~Max{O(4), O(5), 0(8)} = 4; set E ~ b and go to Step 3. Since OA = ~b, go to Step 5. Find a cycle (6, 9, 12, 6). Set E = {6, 9, 12} and go to Step 6 (see Fig. 10d). Since C n E = ~b, set C(2)~{6, 9, 12}; set j ~ 3 and C(3)~q~; O(C(2))+--Max{O(6), O(9), O(12)} = 4; set E+--~b and go to Step 3. Since OA = ~b, go to Step 5. Find a cycle (C(2), 10). Set E = {C(2), 10} and go to Step 6 (see Fig. 10e).

1 1 1 1 2 3 4 5 6 7 8 9 0 1 2 0 ( k )

1

2 3 4 5 6 7 8

9 10 11 12

+ +

+ * + * * ,

+ * , , * + *

* + *

* * .4- * * * , + *

* * * + * *

* * +

* * * +

Fig. 9. The activity-activity incidence matrix.

Page 10: Reengineering of design and manufacturing processes

530 ANDREW KUSIAK et al.

1

4

7

1t3 11 12

1 1 2 3 4 5 6 7 8 9 0

+ * + * *

+ * * *

+ + *

* + * *

* * + *

, • + *

* +

1 1 1 2 O(k)

1 1 2

* 1 1

* 2 2 2 1

* 2 2

+ 2

C 1 1 (1) 6 9 0 2

lo[ ÷ 12 ~

(d)

O(k)

4 2 3 4 1

3 4 5 6 7 8 9

10 11 12

1 2

(a)

1 3 4 5 6 7 8 9 0

r + * *

+ * *

+

P • + *

• + *

• +

(b)

1 1 4 5 6 8 9 0 2

1 1 2

I ,

+

O(k)

1 1 2 3 4 2 4 4 3 4 3 1

CI 4 (2) 0

(e)

o(k)

4 3 4

C C ) ~ O(k)

C(1 5 C ( 2 ) + - . . ~ 4

(f)

4 5 6 8 9

10 12

* + *

* + *

* * +

(c)

o(k)

3 4 2 4 3 4 :i

C (1) O(k)

C(1)[-;] 5

(g)

Fig. 10. The matrix A at various iterations of the modified triangularization algorithm.

Step 6. Since C n E = C(2) ¢ 4), set C(2)~C(2)u{C(2), 10} = {6, 9, 10, 12} O(C(2)),--Max{O(C(2)), O(10)} = 4; set E~4) and go to Step 3.

Step 3. OA *--{C(2)}. Since OA # 4) and C(2) e C, set L(O(C(2)))*-L(O(C(2)))uC(2) = {7, {6, 9, 10, 12}}, where O(C(2) )=4 . Go to Step 4.

Step 4. Delete all entries associated with C(2) from matrix A; set O(C(1))= 5 and OA ,--4); go to Step 2 (see Fig. 10f).

Step 2. Since A # 4), go to Step 3. Step 3. OA *--{C(1)}. Since OA ~ 4) and C(1)e C, set L(O(C(1))),,-L(O(C(1)))uC(1) = {4, 5, 8},

where O(C(1)) = 5. Go to Step 4 (see Fig. 10g). Step 4. Delete entries associated with C(1) from A and go to Step 2. Step 2. Since A = 4), stop.

Solution: Five levels of activities are identified (see Fig. 11): L ( I ) = {1, 2}, L ( 2 ) = {3}, L (3 )= {11}, L(4) = {7, C(2)}, and L(5) = {C(1)}, where C(1) = {4, 5, 8}, C(2) = {6, 9, 10, 12} will be coupled activities.

Page 11: Reengineering of design and manufacturing processes

Design and manufacturing processes 531

1 l i + 2 3

11 7 6 9

10 12 * 4 5 8 *

1 1 1 2 3 1 7 6 9 0 2 4 5 8

141) + * +1/ .(2) * * l ÷ ~3~ c~z~ ,F ~ + 1 . - - - * + V *

, • + *

* * * * 4- * * * 4-

* * C(1)

144)

.1. *

-" + * 145) • +

Fig . 1 I . T h e r e s u l t o f t h e m o d i f i e d t r i a n g u l a r i z a t i o n a l g o r i t h m .

4.2. Act iv i ty based analysis o f I D E F models

Although the algorithm seems best suited for analysis of IDEF3 process flow diagrams, it may be applied to IDEF0 models as well. IDEF0 models attempt to capture the functional components of a system, rather than temporal constraints and flow. However, the ICOM structure of IDEF0 models does imply precedence constraints between functions. For example, an output of one activity may be a control of another activity. This suggests that the first activity is a function that must occur prior to control of the second activity. Furthermore, Mayer et al. [13] acknowledges "activities of an IDEF0 model often correspond very closely to UOBs in an IDEF3 description".

The information contained in the ICOM structure of an IDEF0 model must be preserved during analysis of the model. Therefore, identifying the structure of the model with the triangularization algorithm requires consideration of three types of constraints; (1) output-input constraints, (2) output-control constraints, and (3) output-mechanism constraints. It is also necessary to undo decomposition in order to represent all activities and ICOMs on a single level. Although this violates the basic premise of IDEF0 modeling, it simplifies the representation of the model as a process graph. At this point, three subproblems may be solved, one for each type of constraint. Each subproblem will reveal the structure of the system from a different perspective; the object flow perspective (output-input constraints), the information flow (output--control constraints), and the resource perspective (output-mechanism constraints).

The following example of IDEF0 model analysis using the triangularization algorithm is taken from an industrial company which is deeply involved in process modeling. The process is a small component of the design function at the company. The model contains 27 activities which have been represented on a single level using the ICOM structure. Figure 12 is a process graph of the IDEF0 model of the system. As in the IDEF0 model, inputs, controls, and mechanisms enter the left, top, and bottom of the box, respectively. Outputs leave the right side of the box. The graph in Fig. 12 is used to construct activity-activity incidence matrices for output-input constraints, output-control constraints, and output-mechanism constraints.

The activity-activity incidence matrix for the output-input constraints is shown in Fig. 13. Each non-empty element in the matrix, excluding the diagonal, corresponds to an input in the IDEF0 model. Inputs that come from external sources (i.e. are not an output of an activity in the model) are not included in the matrix. Note that the matrix is nearly in lower triangular form prior to applying the triangularization algorithm.

An activity-activity incidence matrix for the output--control constraints is also constructed for analysis. However, there are no output-mechanism constraints in the model, therefore, no corresponding incidence matrix may be constructed. Very few models observed in the research contain this type of constraint. For most applications, systems utilize resources (or mechanisms) that are generated by external processes or activities. For example, typical mechanisms in this process are personal computers, software, people, etc., all of which are generated by activities outside the scope of the model.

The triangularization algorithm is performed on the matrices for output-input constraints and output-control constraints to identify the model structure from the object flow and information

Page 12: Reengineering of design and manufacturing processes

bo

Fig.

12.

Pro

cess

gra

ph f

or a

ctiv

ity

base

d an

alys

is.

>.

~7

Page 13: Reengineering of design and manufacturing processes

Design and manufacturing processes 533

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27

11 1 2 3 4 5 6 7 8 9 0 1

+

+ +

"31" *

+ • +

+ * +

+ * • +

+

-I-

1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7

+ +

4. *

÷ +

+ * +

+ * +

+ +

+ +

Fig. 13. Activity-activity incidence matrix for output-input precedences.

+

flow perspectives. Figure 14 shows the triangularized matrix for the object flow perspective and Fig. 15 shows the corresponding process graph.

In the object flow perspective of the model, several activities do not impact the process, (i.e. 1, 2, 3, 5, 18, 23, 25, 26, 27). The object flow perspective is based on output-input constraints. By definition, inputs undergo a state transition in an activity to become outputs, i.e. value is added. Therefore, activities not influencing object flow may be considered non-value added activities in the object flow perspective. It must be realized object flow perspective also displays a greater degree of concurrency. This suggests that lead times may be reduced by performing concurrent activities simultaneously. Once again, the degree of concurrency only reflects the constraints in the object flow perspective. The triangularization algorithm only identified two cycles in the process (i.e. 4-6-4, and 9-10-9). Each cycle only involves two activities, suggesting the possibility of an interaction rather than a cycle. In both cycles, the analyst should explore the possibility of combining the functions to create a single activity.

Constraints in the information flow perspective reflect the use of controls, or information, in the process. A control is a piece of information that facilitates execution of the activity (i.e. a written procedure, oral commands, worker experience, etc.). Although an existing control is not trans- formed in an activity, a new control may be produced using inputs and mechanisms. Therefore, the information flow perspective illustrates the evolution of information in the system. The triangularized matrix for the information flow perspective is shown in Fig. 16 and the correspond- ing process graph is shown in Fig. 17. The information flow perspective for the model reveals less concurrency of activities. Three independent groups of activities are determined by the triangu- larization algorithm. Each group of activities may be performed concurrently, however, precedence constraints limit concurrency within the group. One group contains 13 activities and one cycle. Due to output--control constraints, the design process may only be minimized to 10 concurrent levels. Therefore, process lead time is strongly effected by information flow along this path.

Representing an IDEF0 model as a process graph and corresponding activity-activity incidence matrix allows the analyst to perform the triangularization algorithm. Information in the ICOM structure of the model is preserved by considering three types of constraints and the corresponding subproblems. The algorithm identifies concurrent activities and cycles within the structure of the

CAIE 26/:~-H

Page 14: Reengineering of design and manufacturing processes

534

1 2 3 4 6 5 7 9 10 11 12 17 18 19 23 25 26 27 8 14 20 24 15 16 13 21 22

ANDREW KUSIAK el al.

1 1 1 1 1 1 2 2 2 2 1 2 ~ 4 6 5 7 ~ 9 0 1 2 7 ~ 5 6 7

+ + f Cycle 1

+

[ ' ~ + Cycle 2

+ +

+ +

+ +

+ +

4

1 2 2 1 1 1 2 2 8 4 0 4 5 6 3 1 2

+ +

+ +

+

* -I.

Fig. 14. Triangularized matrix for object flow perspective.

E3

Fig. 15. Object flow perspective process graph.

Page 15: Reengineering of design and manufacturing processes

1 14 16 20 22 24 2 15 17 18 25 26 3 19 27 4 5 6 7 8 9 10 11 12 13 21 23

Design and manu~ctufing proces~s

1 1 2 2 2 1 1 1 2 2 12 1 1 1 1 2 2 1 4 6 0 2 4 2 5 7 8 5 6 3 9 7 4 5 6 7 8 9 0 1 2 3 1 3

+

÷

+

+

+

+

+

+

+

+ ÷

+

a~ +

+

÷ * * +

f Cycle 1

*÷1 * + * ~ ÷

+

4

*[~

Fig. 16. Triangularized matrix for information flow perspective.

535

model. Viewing three perspectives of the model allows the user to recognize the impact of object flow, information flow, and resources on the process.

4.3. Software tools for model analysis

The triangularization algorithm presented in this paper is very effective at identifying IDEF model structure. Unfortunately, software tools to support analysis of IDEF models are limited. Two prototype applications have been developed for this research to facilitate model analysis using the triangularization algorithm. However, additional work is needed in the development of a comprehensive modeling and analysis tool. Several potential features of the tool include high quality graphics, a database component for textual information, automatic model building, automatic generation of activity-activity incidence matrices, analysis using the algorithm discussed in this paper, and report generation.

5. C O N C L U S I O N

This paper addressed two issues in IDEF model analysis; observational analysis and analysis of IDEF model structure. Several rules for observational model analysis were presented and related to the constructs of IDEF0 and IDEF3 models. Observational analysis should be considered a starting point for a comprehensive analysis of IDEF models.

A formal analysis using the triangularization algorithm can be performed to identify the underlying structure of an IDEF model. The use of the triangularization algorithm has been extended here as a tool for the analysis of IDEF models. The algorithm requires the representation of an IDEF model as a process graph and corresponding activity-activity incidence matrix. The approach is illustrated with an industrial application. The lack of software tools to support model analysis is recognized and suggested as an area of future research.

Process modeling is a relatively new tool in the analysis of manufacturing and design systems. Focusing future research on the analysis of process models will improve a potentially valuable tool for reengineering manufacturing and design process.

Page 16: Reengineering of design and manufacturing processes

536 ANDREW KUSIAK et al.

Fig. 17. Information flow perspective process graph.

Acknowledgements--This research has been partially supported by contracts from The U.S. Army Tank Automotive Command (contract No. DAAE07-93-C-R080) and Rockwell International Corporation.

REFERENCES

1. T. Demarco. Structured Analysis and System Specification. Prentice-Hall, Englewood Cliffs, NJ (1979). 2. M. Page-Jones. The Practical Guide to Structured Systems Design. Yourdon Press, New York (1980). 3. T. Gane and C. Sarson. Structured Systems Analysis. McDonnell Douglas (1982). 4. P. T. Ward and S. J. Mellor. Structured Development for Real-Time Systems. Yourdon Press, New York (1985). 5. D. J. Harley and I. A. Pirbhai. Strategies for Real-Time System Specification. Dorset House, London (1987). 6. D. T. Ross and K. E. Schoman. Structured analysis for requirements definition. 1EEE Trans. Software Engng SE-3,

6-15 (1977). 7. D. T. Ross. Structured analysis (SA): a language for communicating ideas. 1EEE Trans. Software Engng SE-3, 16-24

(1977). 8. D. T. Ross. Applications and extensions of SADT. Computer, April, pp. 25-34 (1985). 9. G. J. Colquhoun, R. W. Baines and R. Crossley. A state of the art review of IDEF0. Int. J. Comput. Integrated

Manufact. 6, 252-264 (1993). 10. J. S. Busby and G. M. Williams. The value and limitation of using process models to describe the manufacturing

organization. Int. J. Prod. Res. 31, 2179-2194 (1993). 11. A. Kusiak, J. Zhu and J. Wang. Algorithms for simplification of the design process. Proc. 1993 NSF Design and

Manufacturing Systems Conference, Society of Manufacturing Engineers, Dearborn, MI, pp. 1107-1111. 12. U. S. Air Force Integrated Computer Aided Manufacturing (lCAM) Architecture Part lI, Volume IV-Functional

Modeling Manual (IDEFO). Air Force Materials Laboratory, Wright-Patterson AFB, Ohio 45433, AFWAL-tr-81-4023 (1981).

13. R.J. Mayer, T. P. Cullinane, P. S. deWitte, W. B. Knappenbcrger, B. Perakath and M. S. Wells. Information Integration for Concurrent Engineering (lICE) IDEF3 Process Description Capture Method Report, Armstrong Laboratory, Wright-Patterson AFB, Ohio 45433, AL-TR-1992-0057 (1992).

14. R. Tarjan. Depth-first search and linear graph algorithms. SIAM J. Comput. 1, 146-160 (1972). B. I. Blum. Software Engineering A Holistic View. Oxford University Press, New York (1992). D. S. Bowers. From Data to Database. Chapman and Hall, London (1988).