Computers & Industrial Engineering 41 (2001) 135150

www.elsevier.com/locate/dsw

Process analysis and reengineering q

Armen Zakarian a,*, Andrew Kusiak b
a

Department of Industrial and Manufacturing Systems Engineering, University of Michigan, Dearborn, Dearborn, MI 48128-1491, USA b Department of Industrial Engineering, Intelligent Systems Laboratory, The University of Iowa, Iowa City, IA 52242-1527, USA Revised 2 May 2001; accepted 27 June 2001

Abstract To achieve meaningful improvements of the process performance measures such as quality, speed, service, and cost, fundamental rethinking and redesign of the underlying process is required. Numerous corporations have been forced to change their processes in order to survive in a highly competitive market. To perform analysis and reengineering of processes, a structured and unied approach is required. In this paper, a framework based on the IDEF methodology, stream analysis approach, and dynamic simulation for process analysis and reengineering is presented. The stream analysis approach is used for analysis, diagnosis, and management of process changes represented with an IDEF model. To evaluate the impact of changes considered, support the process analysis, and to model performance of the proposed process, a dynamic simulation is used. This study extends the IDEF methodology by including quantitative information. The latter improves IDEF process analysis and reengineering capability, and facilitates the formulation of a dynamic simulation model. The signicance of the results presented in the paper arises from the fact that many companies, e.g. LockheedMartin, General Motors, Rockwell International, are using IDEF for representing their processes. q 2001 Elsevier Science Ltd. All rights reserved.
Keywords: Process modeling; IDEF methods

1. Introduction The process model relates a verbal description of the process system in an ordered sequence of events and activities. Activities in model are arranged in a specic order with the clearly identied inputs and outputs. The output of the process may be either a product or service. Each activity in a process takes an
This manuscript was processed by Area Editor Maged M. Dessouky. * Corresponding author. Fax: 11-313-593-3692. E-mail address: zakarian@umich.edu (A. Zakarian). 0360-8352/01/$ - see front matter q 2001 Elsevier Science Ltd. All rights reserved. PII: S0 3 6 0 - 8 3 5 2 ( 0 1 ) 0 0 04 8 - 1
q

136

A. Zakarian, A. Kusiak / Computers & Industrial Engineering 41 (2001) 135150

input and transforms it into an output with some value to a customer. Ideally, any transformation occurring in the process should add value to the input and create an output that is useful to a downstream recipient. In most cases, processes and organizations that execute them have not been designed using structural approaches rather they have evolved over time in response to the changing business environment. This changing environment might damage a company unless it makes a conscious and constant effort to reengineer own processes to accommodate changes in the market needs and technological innovation. The change is usually made with an explicit and tangible objective of cost reduction and improved efciency and effectiveness (Davenport & Short, 1990). Process reengineering should involve rethinking a broad range of processes in an attempt to improve them. It is important that the model created remain robust in the face of changes, which means that future changes in the process can be easily incorporated in the existing model. Process reengineering covers a variety of perspectives of how to change an organization. It is concerned with the redesign of strategic, value adding processes, systems, policies, and organizational structures to optimize the processes of an organization. A typical process includes three types of activities: value-adding activities activities that are important to the customer; work ow activities activities that move work ow across boundaries that are primary functional, departmental, or organizational; and control activities activities that are created to control value-adding and work ow activities. Strategic processes are those that are of essential importance to company's business objectives. The primary targets of process reengineering are the activities that are both strategic and value adding. The important advantage of process representation over traditional organizational approaches is that it provides a structure of actions. Several process modeling methodologies are currently available and used by various companies, i.e. Computer Integrated Manufacturing Open Systems Architecture (CIMOSA) methodology (Beekman, 1989; European Committee for Standardization, ECN TC310 WG1, 1994). The Object-Oriented Modeling Methodology for Manufacturing (Kim, Kim & Choi, 1993), MOSYS software tool for modeling the functional structure, topology, and control rules of systems (Mertins, Rabe & Stiegennnroth, 1993), Petri Nets (Peterson, 1981). The process reengineering literature also describes a few process modeling techniques. Teng, Grover and Fiedler (1993) presented a framework for examining business processes based two process characteristics: degree of mediation and degree of collaboration. Guidelines were provided for selecting strategic paths in reengineering specic processes. Johansson, McHugh, Pendlebury and Wheeler (1993) presented a simple technique for modeling sequential processes and listed a few other techniques. Tsang (1993) and Sheleg (1993) presented a technique based on business events for reengineering companies, however, they did not support their ideas with a modeling example. Based on some of the above methodologies, a number of process modeling tools have been developed, e.g. ARIS (Germany), FirstStep (Canada), PrimeObjects (Italy), and TEMAS (Switzerland). An important attribute of a modeling technique is extendibility, as a universal modeling technique is not available. Of all methodologies discussed above, the Integrated DEFinition (IDEF) methodology (discussed in the next section) is perhaps the simplest to use and the easiest to extend. It has been broadly accepted by companies to model diverse processes (US Air Force, 1981). Numerous companies have been forced to undertake the change process in order to achieve improvements in critical performance measures. While process reengineering is a challenging task and its results might be signicant, the risks involved in performing such a change are enormous. Hammer (Hammer & Champy, 1993) estimated that 5070% of companies that attempt to reengineer their processes fail. The major concern is associated with a change process itself.

A. Zakarian, A. Kusiak / Computers & Industrial Engineering 41 (2001) 135150

137

Fig. 1. IDEF3 activity box and interface arrows.

To increase the likelihood of a successful change, a comprehensive modeling methodology is required. The methodology developed should help to anticipate the reaction of process participants to the proposed changes. It should also help to evaluate the impact of the changes considered. The IDEF methodology has a descriptive power to represent the process structure. However, most of the process modeling methodologies, including IDEF, are based on informal notation, lacking mathematical rigor, and are static and qualitative, thus making it difcult to use them as analysis tools. The latter is critical to successfully change the process. This paper presents the stream analysis technique and dynamic simulation approach for analysis and reengineering of processes represented with IDEF models. Stream analysis is used in analysis, diagnosis, and management of the change process. To evaluate the impact of the changes considered, a dynamic simulation model is developed. 2. IDEF methodology The IDEF methodology is a structured modeling technique, primarily intended for representing manufacturing systems. Initially, it was developed as a set of four methodologies, IDEF0, IDEF1, IDEF2, and IDEF3, for functional, data, dynamic analysis, and process modeling, respectively (Menzel, Mayer & Edwards, 1994). IDEF3 methodology has been extensively used for modeling manufacturing processes and has been broadly accepted in numerous commercial and government establishments (Loomis, 1987; US Air Force, 1981). One of the main advantages of IDEF3 representation of processes it its simplicity and its vast descriptive power. The IDEF model consists of hierarchically decomposed diagrams, text for each of the diagrams, and glossary of terms used in diagrams (O'Sullivan, 1994). The two basic components of the IDEF3 diagram are a box and an arrow. Boxes represent activities, while the arrows represent interfaces. There are three different interfaces entering and exiting a box: input, output, and control (see Fig. 1). Inputs (I) enter the box from the left, are transferred by the function, and exit the box to the right as an output (O). Control (C) enters the top of the box and inuences or determines the function performed. Replacing activity of the IDEF3 block in Fig. 1 with a function and entering a mechanism (M) interface from the bottom of box results in an IDEF0 block. A mechanism is a tool or resource needed to perform the function. The experience with industrial cases indicates that including a mechanism in IDEF3 is often useful, however, for the application presented in this paper there is no need for using mechanisms. In the recent years, a number of papers have been published on analysis of IDEF models. Belhe and Kusiak (1995) developed a procedure to generate alternative precedence networks from an IDEF3 network of design activities. They proposed an algorithm determining a lower bound on the completion time for the hierarchically structured network by making use of an existing reduction procedure. Ang and Gay (1993) examined the adequacy of IDEF0 methodology and suggested a number of modications and

138

A. Zakarian, A. Kusiak / Computers & Industrial Engineering 41 (2001) 135150

Table 1 The differences between process improvements and process reengineering Process improvement Frequency of change Time required Risk Typical scope One time/continuous Short Moderate Narrow, within function Process reengineering One time Long High Broad, cross functional

enhancements in order to improve its descriptive power for project risk assessment. Kusiak and Larson (1994) integrated techniques for analysis of system reliability with an IDEF3 model. Kusiak and Zakarian (1996a,b) developed a fault tree based methodology for reliability evaluation and risk assessment of parent activities in an IDEF3 model. The minimum path and cut sets generation algorithms for reliability evaluation of IDEF3 models were also developed. The approaches presented in the above papers provide means and tools for analysis and improvement of an IDEF model, however, to achieve fundamental improvements a process reengineering is necessary. The difference between process improvements and reengineering are listed in Table 1 (Davenport, 1993). According to this table, process reengineering should be performed only once. After it is completed, it is subject to process improvements and no other reengineering activities should be performed within an extended period of time, e.g. several years. The table also suggests that business improvements are usually carried out within a single function, whereas business process reengineering is a cross functional concern. It should be emphasized that the latest thinking recognizes that reengineering may range from incremental process improvements to radical changes (Davenport & Stoddard, 1994). Process reengineering is a complex and challenging task. To perform process change, a group of experts need to know what are the component parts (subsystems), how they are put together, and the impact that changing any subsystem may have on other subsystems as well as on the outputs of the system. An IDEF3 methodology provides several important characteristics for successful process reengineering, i.e. (1) process description that species each activity, (2) structure of the underlying process, and (3) ow of objects and their relationship. In spite of these advantages, the IDEF3 methodology alone shows some weaknesses in reengineering processes. To perform the change process successfully, a more effective methodology is required. In addition to being a road map and a guide to a process reengineering effort, the most appropriate methodology should have the following characteristics: be exible enough to address a range of applications and be easy to learn, provide an opportunity and guidance for analysis, prompting the reengineering team to question all aspects of processes and their activities, both as they exist now, and later, once they have been reengineered, provide a mechanism to identify and evaluate the impact of the process changes incorporated as well as an alternative vision for process being reengineered. The objective of this paper is to present a process reengineering framework that easily integrates with the IDEF3 methodology and provides it with all the desired characteristics presented above. The stream analysis approach, used in this paper for process analysis, diagnosis, and management of process changes, is discussed next.

A. Zakarian, A. Kusiak / Computers & Industrial Engineering 41 (2001) 135150

139

Fig. 2. Stream diagnostic chart.

3. Stream analysis approach In order to improve a process, it is important to identify the core problems causing its ineffective functioning. A road map is required to guide the diagnosis of process deciencies, to track down the core problem issues, and to set the stage for effective changes of the process. The stream analysis approach is based on the systems theory and it assumes that a process is open, consisting of subsystems, each including a stream of variables, with many of these variables connected either causally or merely relationally within the same stream or across streams (Porras, 1990). The actions that change one variable are resisted by connected variables, and at the same time, the connected variables are affected by changes in the original variables. Stream analysis graphically represents relationships in a process. Similar to IDEF3 and unlike other system analysis approaches, in the stream analysis, numerous interrelationships between subsystems are charted to facilitate visual analysis by tracking through the charts and identifying sets of related problems. These problems can be extracted from the charts and analyzed separately. Stream analysis is procedural in nature and it outlines the necessary steps and procedures needed to carry out the change process. It makes possible to chart out the problems identied in the key variables of the underlying process. As a new technique for analysis, planning, and tracking process changes, stream analysis has several important characteristics that uniquely contribute to the process of managing the planned changes of an IDEF3 model. First, similar to IDEF it is graphics-based, which is central to its effectiveness as users visually observe complex phenomena, and understand them to a greater depth. A second characteristic of the stream analysis approach is that it allows one to determine what is wrong, what to do about it, and keeps track what has been done. It makes a process more comprehensible to all members of the organization, not just those involved in the change process. Therefore, it serves as a communication device, useful in informing different layers of an organization about what is going on. Since much resistance to the change may occur due to uncertainty about the future, the charts generated by this approach facilitate organizational awareness of the potential changes.

140

A. Zakarian, A. Kusiak / Computers & Industrial Engineering 41 (2001) 135150

Fig. 3. Stream analysis and simulation applied to process models.

The stream analysis approach is based on creating graphical representations of two central components of any planned organizational change process: system diagnosis and planning intervention. 3.1. System diagnosis System diagnosis is based on a graphical representation of problems identied in a process in the form of a chart, called the stream diagnosis chart, which is divided into columns (streams), one for each organizational dimension considered. Each problem, after being identied, is placed in an appropriate column. The next step is to specify the key interconnections that exist among the identied problem areas as arrows drawn on the chart. An example stream diagnostic chart is shown in Fig. 2. 3.2. Planning intervention Planning the change activities can be accomplished with a chart, similar to the one used for diagnosis. The technique requires that actions taken to intervene into the process be placed in a column representing the process dimension affected the most by the intervention. The actual phases through which the stream analysis is performed are as follows (Porras, 1990): 1. 2. 3. 4. 5. 6. forming a change management team; collecting data; categorizing problems; identifying interconnections; analyzing the problem chart; formulating an action plan.

The rst two phases of stream analysis are similar to what is done in most change approaches, i.e. the formation of a cross-functional team of the organization members to guide and monitor the change process and data collection procedure. Therefore, these two phases are not addressed in this paper. The remaining phases of the stream analysis approach are illustrated in the example presented in Section 4.

A. Zakarian, A. Kusiak / Computers & Industrial Engineering 41 (2001) 135150

141

Fig. 4. IDEF3 model of an R&D project.

4. Analysis methodology This section presents a methodology that utilizes stream analysis and dynamic simulation for effective reengineering of IDEF3 process models as shown in Fig. 3. The stream analysis technique is used for analysis, diagnosis, and management of the change process. To evaluate the impact of the changes considered, support the process analysis, and to model performance of the proposed process, a dynamic simulation model is developed. Many of these concepts are explained in the example presented next. 4.1. Illustrative example Consider the IDEF3 representation of the research and development (R&D) process in a manufacturing company (see Fig. 4). Assume that the team responsible for management of large scale R&D projects intends to redesign the project management process to minimize the time overruns. The process in Fig. 4 begins with the project evaluation where the entire project is divided into a number of activities. Knowing the productivity of personnel, the number of tasks required, and subsequently the effort remaining, a project management determines the required level of personnel to complete the project in the time allotted. Once the level of personnel and the effort required for the project are determined, the time needed to complete the project is evaluated and the completion date is scheduled. After all major activities of the system have been determined, the reengineering team is selected to answer key questions, i.e. what are the major problems causing improper functioning of the process, which processes should be reengineered, what actions should be taken. To answer these questions, the stream analysis approach is deployed. Based on the major process activities in Fig. 4, the change team divided the system considered in Fig. 4 according to four major dimensions (streams): (1) management arrangements, (2) social issues, (3) evaluation procedures, and (4) the customer. Using the company records, interviewing the management, questioning the employees, and observing the process, the change team collected the information required about the problems that causes improper functioning of the system. Based on the information collected, the following was revealed. The major concern of the management was poor customer satisfaction due to constant time overruns and improper evaluation of completion dates of projects. In addition, the management was concerned with improper evaluation of the time and effort required for the

142

A. Zakarian, A. Kusiak / Computers & Industrial Engineering 41 (2001) 135150

Fig. 5. Stream diagnostic chart corresponding to the IDEF3 model in Fig. 4.

completion of each project. The personnel were not satised with the company hiring policy. It has been determined that the level of personnel required to carry out an initial workload for a new project, was not properly determined. Company records indicated that the personnel turnover rate was high. Observation of the process revealed that the personnel were uncertain about their future and the average performance was low. Once the problem statements are generated, a stream diagnostic chart is created and each problem is placed in its appropriate column. After the problems have been classied, the analysis is conducted to determine how they are interconnected. The resultant diagnostic stream chart is shown in Fig. 5. Once the stream diagnostic chart in Fig. 5 has been created and approved by the team, the next step is to identify and separate the core problems from the symptoms. Symptoms (caused by deeper problems) are often driven by a relatively large number of other problems. For example, the symptom labeled in Fig. 5 as C2 is `Poor customer satisfaction due to large number of delays'. The arrow pointing into problem C2 signies one or more problems causing it. Removing the symptoms will not do much to eliminate the problems that cause them and, consequently, they are likely to return either in the same or altered form. The second problem type reected in the chart in Fig. 5 is similar to M1 `No formal hiring policy', M2 `No formal mechanism for hiring', S1 `Initial personnel is not properly identied', and P1 `Lack of information about the number of tasks completed'. These problems have arrows coming out of them signifying that they are causing other problems in the process. Therefore, problems M1, M2, S1, and P1 are the core problems and solving them should eliminate all the problems that they cause. Analysis of the stream diagnostic chart in Fig. 5 indicates the four core problems M1, M2, S1, and P1

A. Zakarian, A. Kusiak / Computers & Industrial Engineering 41 (2001) 135150

143

Fig. 6. Stream planning chart of the IDEF3 model in Fig. 4.

cause a cluster of connected problems that eventually lead to the symptom C2. Tracking back through the problem chart the following fact, that explains the reason for malfunction of the process in Fig. 4, is revealed. The core problems M1, M2, and S1 result in frequent personnel changes and layoffs, which in turn cause uncertainty about the future among the personnel and poor productivity. Subsequently, many of the evaluation procedures based on an average productivity and level of the personnel appear to be not adequate. Moreover, the core problem P1 creates another chain of problems, similar to P2 and P3, that negatively impact the evaluation procedures of the company. One consequence of this situation is an improper evaluation of the completion date that causes high number of delays, frequent overruns, and poor customer satisfaction. Another observation from the chart in Fig. 5 is that most of the arrows going into the social factors stream originate in the management arrangement stream. Once the diagnosis is completed, the next step in the stream analysis approach is to create an action plan consistent with the problems identied. The action to be taken is represented by activities, which are placed in columns corresponding to the stream of the most strongly affected processes. Certain types of activities affect more than one process stream. In this case, the activity is placed in the stream it affects the most or in the stream containing the problem targeted for change by the activity. The stream planning chart in Fig. 6 shows the three major activities designed to deal with the core problems M1, M2, and S1 that have been identied in the diagnosis. First, in the management arrangement

144 A. Zakarian, A. Kusiak / Computers & Industrial Engineering 41 (2001) 135150

Fig. 7. Modied IDEF3 process model corresponding to the stream planning chart in Fig. 6.

A. Zakarian, A. Kusiak / Computers & Industrial Engineering 41 (2001) 135150

145

stream the two activities, i.e., `Determine time to hire' and `Determine desired level of personnel', are created. These two activities determine hiring/ring policy of the organization which is represented by the activity `Determine hiring rate' and is placed in the social factors stream. The latter controls the actual level of personnel required to complete the project on time. Although the newly designed activity, `Determine hiring/ring rate', determines the human resources required it is essential for the management to choose an optimal level of initial personnel that reduces hiring/ring and consequently improves the productivity of personnel. To deal with the core problem P1 `Lack of information about the number of tasks completed' one needs a feedback loop between the activities `Evaluate tasks remaining' and `Evaluate number of tasks completed', as the process without such a loop might be ineffective and uncertain. Therefore, an arrow is drawn that enters the top of the box representing activity `Evaluate tasks remaining' and signies the output of the activity `Evaluate number of tasks completed' and controls the evaluation procedure of activity `Evaluate tasks remaining'. The main advantage of preparing an improved process model is that a clear mapping from problems to actions is shown in the same format as the problem diagnostic chart. Once the stream planning chart in Fig. 6 is developed, one needs to analyze the impact of the changes considered. A framework for dynamic analysis of the IDEF3 process model in Fig. 4 is presented in Section 5. 5. Dynamic analysis of processes An IDEF3 model is static and qualitative which makes it difcult to use it in analysis of the change process. It is based on informal notation that lacks mathematical rigor. The consequence is that one cannot manipulate the model, and drive quantitative and meaningful results for process analysis (Busby & Williams, 1993). For example, the IDEF3 representation of the process in Fig. 4 clearly indicates the relationships between activities, however, no quantitative results can be extracted from this model. The model does not provide any information on how the initial level of personnel impacts the hiring/ring policy of the company, or how the process behaves under different initial inputs, or how many tasks are completed within a certain time interval. To improve the power of an IDEF3 model in quantitative and dynamic analysis of processes a number of modications and enhancements are proposed next. To illustrate the proposed modications, consider the modied IDEF3 model in Fig. 7. Each activity box here is divided into two sections. In the upper section of each box a phrase describing the activity is included. The lower section of the box contains an expression, which describes the mathematical relationship of the output, input, and control. The latter serves the important purpose of describing how the activities of a particular process affect its performance and it illustrates how one activity impacts another one. For example, consider the activity `Evaluate effort remaining' in Fig. 7. The two interfaces, i.e., input (`tasks remaining') and control (`productivity') entering the activity box, determine its output. The mathematical expression in the lower section of the activity box describes the relationship between the output (`effort remaining'), input (`tasks remaining'), and control (`productivity'). In this mathematical expression `productivity' appears in the denominator, implying the higher productivity results in less effort required to complete the project, whereas, the variable `tasks remaining' is in the numerator meaning, the more tasks remain the higher effort is required to complete the project. The validity of the expressions can be also veried by the units of variables used in the formula. For example, the unit of variable `tasks remaining' and `productivity' is `tasks' and `tasks/person/month', respectively. Therefore,

146

A. Zakarian, A. Kusiak / Computers & Industrial Engineering 41 (2001) 135150

Fig. 8. The system ow diagram of the IDEF3 process model in Fig. 7 represented with the notation of system dynamics.

`tasks remaining' divided by `productivity' yields man months of effort required to complete the project. Similar to the example presented above, one can create an expression for each activity of the process using its output, input, and control. It should be emphasized that mathematical expressions developed for the activities should relate activity output to its input and control. The latter should be used as a guideline when developing mathematical expressions for the activities. The resultant modied IDEF3 process model is presented in Fig. 7. The enhanced IDEF3 model provides the mathematical vigor and sets the stage for formulation of a dynamic simulation model of the process. To illustrate the latter, consider a system ow diagram corresponding to an IDEF3 process model represented with the system dynamics notation in Fig. 8. The system ow diagram in Fig. 8 corresponds to the model in Fig. 7. One can easily detect similarities between the model in Figs. 7 and 8. Once the system ow diagram in Fig. 8 is developed, one needs to formulate a dynamic simulation model for dynamic analysis of the process. The model formulation is the transformation of the model in Fig. 8 from its informal, conceptual view to a formal quantitative representation in the form of equations. One can see that the transformed model is represented by the modied IDEF3 model in Fig. 7. Therefore, using the modied IDEF3 representation one can easily formulate a dynamic simulation model of the IDEF3 process model in Fig. 7. The dynamic simulation model was built using the DYNAMO modeling language (Richardson & Pugh, 1981). The model represents a set of linked differential equations describing a closed loop feedback system. Dynamic properties of the model can be analyzed by providing it with an appropriate set of

A. Zakarian, A. Kusiak / Computers & Industrial Engineering 41 (2001) 135150

147

Fig. 9. Simulation output for the initial level of personnel 10.

parameters, initial conditions, and obtaining solutions with numerical integration procedures. As mentioned earlier, the stream analysis approach uses open loop thinking, meaning it approaches the problem without using a feedback. In the stream analysis, one discovers a problem, reasons about it, develops a plan to deal with it, and then acts according to the plan developed. Usually forgotten here is

Fig. 10. Simulation output for the initial level of personnel 110.

148

A. Zakarian, A. Kusiak / Computers & Industrial Engineering 41 (2001) 135150

Fig. 11. Simulation output for the initial level of personnel 50.

the fact that any action alters the state of the process, resulting in a new understanding of the problem. The purpose of dynamic analysis of the process is to determine the behavior of the system under different initial inputs, perform repeated experimentation with the process, and alternate the management policies. A dynamic analysis of the IDEF3 model in Fig. 7 is presented next. To illustrate dynamic analysis of the IDEF3 model in Fig. 7 it is assumed that the entire project, considered in the illustrative example of Section 4, is divided into 45,000 tasks and the required completion date of the project is 30 months. Furthermore, it is also assumed that the average person productivity is 30 tasks/person/month and the management wants to determine the optimal level of the initial personnel thus resulting in less hiring/ring and allowing completion of the project on time. Figs. 911 show the simulation results of the process model in Fig. 7 for the initial values of personnel 10, 110, and 50, respectively. One can see from Fig. 9, that when the project is initiated with 10 people, then within rst 10 months 45 more employees are hired to meet the required completion date of the project. When the project begins with 110 people (see Fig. 10), then in the course of the project it is realized that almost 68 people need to be red within the rst 10 months. Fig. 11 shows that when the project is initiated with 50 people, then during the next 30 months only one additional person is hired to meet the required completion date of the project. Similar analysis of the model can be performed for other variables of the system and different values of the initial inputs. Since the objective of this study is to present a dynamic simulation framework for IDEF3 models and not to discuss detailed analysis of the models, further details of the analysis are not necessary. 6. Conclusions Reengineering involves changes in processes in the quest for signicant improvement of an organization.

A. Zakarian, A. Kusiak / Computers & Industrial Engineering 41 (2001) 135150

149

Implementing changes in the organization is an effort that is prone to failure. To increase the likelihood of successful change one needs a comprehensive modeling tool. This study provides a methodology that utilizes the newly developed concepts based on stream analysis, dynamic simulation for effective reengineering of processes represented with an IDEF3 model. The stream analysis approach is used for analysis, diagnosis, and management of the change process. To evaluate the impact of the changes considered, support analysis of the process, and to model performance of the proposed process, a dynamic simulation model was developed. This study also presented a number of modications that provided an IDEF3 with quantitative information, improved its power in process analysis and reengineering, and facilitated the formulation of a dynamic simulation model. The application of the methodology developed in the paper was presented with the industrial study. The modeling experience with industrial example shows that the IDEF3 process modications presented in this paper may allow easy integration of IDEF3 methodology with the dynamic simulation approach. Using predened templates, these two approaches can be interfaced once mathematical expressions for IDEF3 process activities are obtained. Modeling experience also shows that using IDEF3 graphical syntax in stream analysis charts, e.g., in stream planning chart, will make these two techniques more compatible and the methodology easier to implement. Furthermore, the experience shows that activities that are qualitative in nature, e.g. activities representing cultural issues, are difcult to document, model, and quantify. To avoid the latter mentioned difculties one may consider modeling these activities as controls in IDEF3 model. Future research will concentrate on developing templates and formal techniques for combining the approaches developed in this paper. References
Ang, C. H., & Gay, R. (1993). IDEF0 modeling for project risk assessment. Computers in Industry, 22 (1), 3145. Beekman, D. (1989). CIMOSA: Computer integrated manufacturing open system architecture. International Journal of Computer-Integrated Manufacturing, 2 (2), 94105. Belhe, U., & Kusiak, A. (1995). Resource constrained scheduling of hierarchically structured design activity networks. IEEE Transactions on Engineering Management, 42 (2), 150158. Busby, J. S., & Williams, G. M. (1993). The value and limitations of using process models to describe the manufacturing organization. International Journal of Production Research, 31 (9), 21792194. Davenport, T. H. (1993). Process innovation, reengineering work through information technology, Boston, MA: Harvard Business School Press. Davenport, T. H., & Short, J. (1990). The new industrial engineering: information technology and business process redesign. Sloan Management Review, Summer, 1127. Davenport, T. H., & Stoddard, D. B. (1994). Reengineering business change of mythic proportions?. MIS Quarterly, June, 121 127. European Committee for Standardization (ECN) TC310 WG1 (1994). An evaluation of CIM modeling constructs: evaluation report of constructs for views according to ENV 40 003. Computers in Industry, 24 (23), 159236. Hammer, M. S., & Champy, J. (1993). Reengineering the corporation: a manifesto for business revolution, New York: Harper Business. Johansson, H., McHugh, P., Pendlebury, J., & Wheeler III, W. (1993). Business process reengineering: Breakpoint strategies for market dominance, New York: Wiley. Kim, C., Kim, K., & Choi, I. (1993). An object-oriented information modeling methodology for manufacturing information systems. Computers and Industrial Engineering, 24 (3), 337353. Kusiak, A., & Larson, N. (1994). System reliability and risk assessment: a quantitative extension of IDEF methodologies, Stanford University: Proceedings of the AAAI Spring Symposium Stanford, CA, Stanford University Press, Stanford CA. pp. 8893.

150

A. Zakarian, A. Kusiak / Computers & Industrial Engineering 41 (2001) 135150

Kusiak, A., & Zakarian, A. (1996). Risk assessment of process models. Journal of Computers and Industrial Engineering, 30 (4), 599610. Kusiak, A., & Zakarian, A. (1996). Reliability evaluation of process models. IEEE Transactions on Components, Packaging, and Manufacturing Technology Part A, 19 (2), 268275. Loomis, M. E. (1987). The database book, New York: Macmillan. Menzel, C., Mayer, R. J., & Edwards, D. D. (1994). IDEF3 process descriptions and their semantics. In C. H. Dagli & A. Kusiak, Intelligent systems in design and manufacturing (pp. 172212). New York: ASME Press. Mertins, K., Rabe, M., & Stiegennnroth, H. (1993). Analyzing production systems using petri net based functional techniques, Proceedings of the International Conference on Industrial Engineering and Production Management, Vol. 2. Mons, Belgium: FUCAM pp. 961-970. O'Sullivan, D. (1994). Manufacturing systems redesign: creating the integrated manufacturing environment, Englewood Cliffs, New Jersey: Prentice Hall. Peterson, J. L. (1981). Petri net theory and the modeling of systems, Englewood Cliffs, N.J: Prentice Hall. Porras, J. I. (1990). Stream analysis: a powerful way to diagnose and manage organizational change, Menlo Park, CA: Addison Wesley. Richardson, G. P., & Pugh, A. L. (1981). Introduction to system dynamics modeling with DYNAMO, Cambridge, MA: Productivity Press. Sheleg, W. (1993). Business process reengineering driven by business events. Database Newsletter, 21 (5), 1225. Teng, J. T. C., Grover, V., & Fiedler, K. D. (1993). Business process reengineering: charting a strategic path for the information age. California Management Review, 36 (3), 931. Tsang, E. (1993). Business process reengineering and why it requires business event analysis. Case Trends, March, 815. US Air Force (1981). Integrated Computer Aided Manufacturing (ICAM) Architecture Part II, Volume IV-Functional Modeling Manual (IDEF0), Ohio 45433: Air Force Materials Laboratory, Wright-Patterson AFB AFWAL-tr-81-4023.