The Increasing Need for Integrating Simulation and Collaboration to ...

Proceedings of the 37th Hawaii International Conference on System Sciences - 2004

The Increasing Need for Integrating Simulation and Collaboration to Support Change Management Programs Mariëlle den Hengst Delft University of Technology the Netherlands [email protected]

Vlatka Hlupic Brunel University United Kingdom [email protected]

Abstract Integrating simulation and collaboration to support change management programs is not yet an often used practice. Both simulation and collaboration are said to have added value for change management programs, yet their integration is fairly new. We identify the need for integrating simulation and collaboration for four different change management programs: TQM, JIT, BPR, and PI. It appears that the need for integration for the newer approaches (BPR and PI) is greater than for older approaches (TQM and JIT). This finding is supported by two case studies, one focusing on TQM/JIT and one focusing on BPR/PI. The case studies furthermore show that integration is difficult because of the lack of proper support tools.

1. Introduction To stay efficient and effective in today’s changing environment, organizations must continuously adapt their structure, processes, and technologies to new conditions [3], [7], [13], [18], [28], [29], [31]. As a response to this need for constant change and improvement various change management approaches have been developed. Every few years, a new management philosophy, method, or technique is developed which is believed to enhance business performance [20]. Yet, the rethoric surrounding their success is always more convincing than the reality. Indeed, there are many criticisms about the lack of success of these change management programs in the workplace [18], [21]. Several means are mentioned in literature to improve the success rate of change management programs. Two of these means are selected here: simulation and collaboration. Simulation provides a structural environment in which one can understand, analyze, and improve business processes. Simulation captures the processes of an organization system, and also supports the quantitative evaluation of different alternatives [25]. Collaboration refers to situations where two or more

Wendy L. Currie Brunel University United Kingdom [email protected]

people act together to achieve a common goal. Collaboration between stakeholders in change management programs is regarded crucial for the success [14]. Simulation related research and empirical work have been traditionally associated with areas such as operational research and management science. In contrast, collaboration is mainly being researched by business, management, and IT communities. Simulation and collaboration appear to be separated in literature. In this paper we show that they are increasingly inseperable in the practice of change management programs. In section 2 we focus on four well known change management programs: Total Quality Management (TQM), Just In Time (JIT), Business Process Reengineering (BPR), and Process Innovation (PI). We investigate the applicability of simulation and collaboration to support each of these change management programs in section 3. Section 4 then describes two case studies to illustrate the increasing need for integrating simulation and collaboration. Section 5 concludes this paper with directions for further research to make the integration between simulation and collaboration successful.

2. Change management programs The analysis of relevant literature reveals that there have been very few comparative studies on change management programs [5]. In the paragraphs following we will describe four change management programs. In the next section we compare the programs on the applicability of simulation and collaboration. Total Quality Management (TQM) TQM was first developed by US writers such as Crosby [4], Deming [10], and Juran [19]. TQM is concerned with quality improvement on a company-wide basis. It is a comprehensive approach to improving competitiveness, effectiveness, and flexibility through planning, organizing, and understanding all the activities

0-7695-2056-1/04 $17.00 (C) 2004 IEEE

1

Proceedings of the 37th Hawaii International Conference on System Sciences - 2004

and tasks undertaken by people within an organization. The core of TQM is about improving internal and external customer and supplier relationships. The key objective is for suppliers to continually seek to improve the way they interact with their customers. Just In Time (JIT) JIT in general relates to methods aimed at reducing inventory levels. Although the Western countries often see JIT in the narrow context of inventory control, in Japan JIT has been viewed as a management philosophy of integrated manufacturing, planning, and control. Business Process Reengineering (BPR) BPR emerged in the late 1980s and early 1990s as a new approach to managing innovation and change. It was designed to be highly prescriptive since it advocated that managers should constantly seek new and improved methods and techniques for managing and controlling core and service business processes. BPR is not a step by step, incremental approach, but it is rather a radical change program [17], [18]. It includes all components that make up an organization: processes, products, services, people, and technologies. Process Innovation (PI) Perhaps as a result of direct competition with Hammer and Champy [18], Davenport [7] developed the concept of process innovation, which he claimed was different from process improvement. PI was an ambitious change management program designed to integrate information technology and human resource management to improve the business performance. As with BPR, it focuses upon company-wide innovation and change. Comparison of change management programs There are many similarities between the change management programs, see also Currie and Hlupic [6]. They all focus on the improvement of business performance. As we can see, TQM has many similarities with BPR and PI. Moreover, JIT, according to some observers, incorporates many of the concepts and practices of TQM. The differences between BPR and PI are more to do with labeling rather that substance, scope, and practice. Besides the similarities, differences between the change management programs exist as well. TQM and JIT emphasize the role of ‘shop floor’ staff in a continuous improvement process. Improvements are usually manufacturing oriented and focus on the flow of physical objects. The more recent approaches BPR and PI are concerned with how technology can be used to provide seamless and efficient business processes. Improvements in BPR and PI normally deal with the flow of information and how resources may be redeployed. A strong ‘people’

orientation is apparent in BPR and PI, while TQM and JIT have a strong manufacturing focus. TQM and JIT should be used to keep a company’s processes tuned up between the periodic process replacements that only BPR and PI could accomplish [18]. TQM and JIT are built into a company’s culture, can go on working without much day-to-day attention from management. BPR and PI in contrast are an intensive topdown, vision driven effort that requires non-stop senior management participation and support [18].

3. Simulation, collaboration and the change management programs In the next subsections we describe the added value of simulation, of collaboration, and of the integration of simulation and collaboration to change management programs.

3.1 Simulation and the change management programs Simulation models describe processes in the organization system with graphical symbols, as conceptual models do, and provide quantitative information about these processes. Conceptual models provide a static view of the processes being studies. Some models provide basic calculations, for example, of process times. However, most conceptual models are not able to conduct ‘what if’ analyses. Nor are they able to show a dynamic change in business processes and evaluate the effect of stochastic events and random behavior of resources. Simulation models, on the other hand, offer wider opportunities for understanding business processes. Besides capturing the processes, simulation also supports the quantitative evaluation of different alternatives. Quantitative process metrics addressed by simulation are costs, cycle time, serviceability, and resource utilization. The visual interactive features of many simulation packages allow multi-disciplinary team members to understand the model and communicate about it [25], [32]. Simulation models of business processes can help overcome the inherent complexities of studying and analyzing businesses, and therefore contribute to a higher level of understanding and improving these processes. Despite this potential, simulation is not common to be used in change management programs [6]. To describe the added value of simulation for each of the four change management programs, we focus on three aspects: what is being modeled, how are the models used, and on what time scale, see also figure 1. TQM and JIT have a strong manufacturing focus. The simulation model will show the flow of physical objects through the several parts of the organization. BPR and PI have a strong people orientation and focus on the flow of information and how resources may be redeployed. Simulation models can be used here as well [24]. Although information is not always as

0-7695-2056-1/04 $17.00 (C) 2004 IEEE

2

Proceedings of the 37th Hawaii International Conference on System Sciences - 2004

physical as the goods being modeled with TQM and JIT, the flow of information can be modeled as a flow of entities being it physical or ‘virtual’. And simulation models can capture the behavior of both human and technical resources in the system. Looking at how the models are used, we notice a difference between TQM/JIT and BPR/PI as well. TQM and JIT focus on continuous improvement. A simulation model can be easily modified to follow changes in the real system and as such can be used as a decision support tool for continuous process improvement [24]. Used in this way, it is especially the quantitative outcome of the simulation model that is being used. BPR and PI focus on radical change instead of continuous improvement. Simulation models of non-existing business processes can be developed for this [24]. The added value of simulation in these cases is much less the quantitative outcome of the model. The simulation model is used much more for creating understanding. BPR PI understanding

are needed. Top managers are identified as ‘catalysts’ of change management programs [12]. Top managers have the authority to make decisions. We use the term decision makers from now on for the so called top managers, and the term problem owners for middle managers. Besides problem owners and decision makers, another group of stakeholders is identified: the analysts or consulting team. Analysts bring in the knowledge on the change management program. Most often this knowledge is not available within the organization and it needs to be brought in from outside by analysts. The involvement of stakeholders is different for each of the change management programs, see also table 1. TQM and JIT focus on continuous improvement and involve mainly the problem owners. At the start-up of TQM and JIT decision makers probably are involved, but once in place TQM and JIT are carried out by the problem owners. BPR and PI focus on radical change and have a strong orientation on involvement of decision makers. Traditionally, participation was exclusively for decision makers [17], [18]. According to traditional approaches, problem owners are to be avoided because they lack the vision and the authority. A few outsiders are to be invited to bring objectivity and a different view. However, there is evidence that it is important and successful to include knowledge and build support from the bottom as well by inviting problem owners [2], [8], [12], [27].

use of models

e

e tim

ale sc

us uo in nt co information objects human resources

physical objects technical resources

objects being modeled

problem owner

tim

JIT outcome

Table 1: Collaboration and the change management programs (the darker the color, the higher the participation)

e on

TQM

Figure 1: Simulation and the change management programs

3.2 Collaboration and the change management programs Collaboration between stakeholders in a change management program is important for several reasons: to deal with complexity, to increase the level of acceptance, and to keep up to date with the latest organizational developments [33]. Different stakeholders can be identified in a change management program. Middle managers often form the core of the change management program. Problems to be addressed in the change management program and the changes that are to be implemented most often relate directly to the daily work of middle managers. Middle managers are confronted with the problems, but lack the vision and the authority to start a change management program. That is why top managers

decision maker

analyst

TQM JIT BPR PI Involving stakeholders is important, but challenging the same time. It appears to take quite a long time to involve many different stakeholders with different disciplines. To deal with these challenges, group support systems can be used. GSS are designed to improve the efficiency and effectiveness of meetings by offering a variety of tools to assist the group in the structuring of activities, generating ideas, and improving group communications [22], [23], [30]. Previous studies on GSS in general have reported labor cost reductions averaging 50% and reductions of project calendar days averaging 90% [16], [26]. Time reductions are also reported for applications in change management programs [9], [11].

3.3 Simulation, collaboration and the change management programs In the previous subsections it has been shown that simulation and collaboration have added value for change management programs. In this subsection we show that

0-7695-2056-1/04 $17.00 (C) 2004 IEEE

3

Proceedings of the 37th Hawaii International Conference on System Sciences - 2004

there is an increasing need to integrate simulation and collaboration. To do so, we focus on the steps that need to be taken in a simulation project. We identify which stakeholders should collaborate in which steps and further specialize this to the different change management programs. Various approaches exist to conduct a simulation study. A well known approach is described by Banks et al. [1]. They distinguish the steps as presented in figure 2. After the problem has been formulated (1) and the objectives are set (2), the problem situation in an organization is conceptualized (3) in order to structure the problem situation. Next, a descriptive empirical model is built that can be used to analyze and diagnose the problem situation. For this purpose, data about the problem situation is collected (4) and the model is implemented in a simulation language (5). Before the model can be used, it must be checked whether it is a good representation of the problem situation. First, the model is verified to ensure that it behaves as intended (6). Then, the model is validated to test the (statistical) correspondence between the model and the problem situation (7). If this check is passed, the empirical model can be used to identify causes and effects of the problem. Based upon the results of the problem diagnosis, several alternative solutions may be generated. The alternative solutions are worked out in detail in a number of prescriptive empirical models (8). These models can be experimented with to study the effects of the alternatives in more detail (9). When the solutions are not satisfying enough, new alternatives can be constructed to run experiments with (10). The actual choice is made based on the results of the experiments among others. The results of the analyses are reported about (11). And, finally, in order to actually solve the problem situation, the solution must be implemented (12). In each of the steps of a simulation study, stakeholders exchange information, see table 2. The analysts are model experts, they build models, but do not know the business. The problem owners have detailed knowledge about certain processes, do hardly have modeling experience, and do not have a helicopter view over the organization. The decision makers lack detailed knowledge of the processes, but have an overall view on the organization. Problem owners and decision makers communicate with each other to formulate the problem. Then the analysts enter the picture and they start to communicate with problem owners and decision makers to set objectives. The problem owners and the analysts collaborate to conceptualize the problem and to collect the data. The analysts then build and verify the model. The problem owners together with the analysts validate the model. The problem owners, the decision makers, and the analysts discuss the results of the simulation model and design alternatives. The analysts build the models for the experiments and the results are presented to the problem

owners and the decision makers. Finally, the decision makers decide on which alternative to implement. (1) problem formulation (2) setting objectives and project plan (3) conceptualization

(4) data collection

(5) model translation

(6) verification

(7) validation

(8) experimentation yes (9) evaluation

(10) more runs? no

(11) report

(12) implementation

Figure 2: Simulation steps [1]

Table 2: Involvement of stakeholders in different simulation steps

problem owner

decision maker

analyst

(1) problem form. (2) setting objectives (3) conceptualization (4) data collection (5) model translation (6) verification (7) validation (8) experimentation (9,10) evaluation/runs (11) report (12) implementation Now, we differentiate this picture for each of the change management programs. For TQM and JIT, the problem owners are the most important stakeholders, the simulation model is used for continuous improvement, and the quantitative outcome is most relevant. In practice, a simulation model will be built. For the construction of the model (steps 1 through 7) collaboration between the

0-7695-2056-1/04 $17.00 (C) 2004 IEEE

4

Proceedings of the 37th Hawaii International Conference on System Sciences - 2004

stakeholders as indicated in table 3 is important. Once the model is finished, it will be used for experimentation and evaluation (steps 8 through 10). This will be a continuous effort of problem owners and analysts, without the direct involvement of decision makers. Small changes to the organization will be tried out with the simulation model and if proven successful they will be implemented. For BPR and PI, the decision makers play a very important role next to the problem owners. With TQM and JIT, problem owners are the most important stakeholders, especially in steps 8 through 10. With BPR and PI, decision makers play a very important role as well. Simulation models are used for one time radical improvements with BPR and PI. With TQM and JIT, the model can be used for a long time, but with BPR and PI, the steps are carried out just once. And, the simulation model is mainly used to create understanding of the situation with stakeholders involved. The quantitative outcome is of less relevance. Discussion about the results is of greater value than presentation of the numbers. Collaboration, therefore, is more important than with TQM and JIT. The above analysis shows that the need for integrating simulation and collaboration is higher for BPR and PI than for TQM and JIT. When we put the change management programs on a time scale, we could state that there is an increasing need to integrate simulation and collaboration. TQM and JIT are two management approaches that emerged in the early 1980s. BPR and PI emerged about a decade later. In the next section we describe two case studies, one on TQM/JIT and one on BPR/PI. These case studies support the notion that the need for integration of simulation and collaboration is different for different change management programs. The cases, furthermore, show that the integration of simulation and collaboration is difficult.

4. Case studies In this section we describe two case studies in which a change management program was carried out with the use of simulation models and collaboration techniques: mail logistics at a Dutch Insurance Company [15], and redesign of a Dutch cargo handler. The cases were selected based on the serious nature of the problem at hand and the willingness of the involved organizations to participate in activities that served research goals, such as interviews. During the case studies, notes were kept by all researchers involved. We compared these notes and looked for common themes and insights. Moreover, we carried out informal interviews with people involved. These interviews addressed various issues, including trust in the results, the factors this trust is based on, the representation of the results, understandability of the model, insight in the modeled situation, and commitment to the results. The role of the researcher in the case studies was multi-faceted. We supported the problem owners in the case situation by constructing and running simulation models. Moreover, we facilitated collaboration between the stakeholders. Our interventions were exclusively focused on supporting the change management program and subsequently learning from that. We had no personal stake in any of the problem situations or opportunities that were to be explored.

4.1 Mail logistics at a Dutch Insurance Company A Dutch Insurance Company (DIC) receives a great number of documents each day: about 7000 documents per day on average. Most insurance intermediaries send a number of documents with different destinations within DIC in one envelope. The grouping of documents is the key to the current arrangements at the mail room: many envelopes have to be opened to examine and sort the documents they contain. Mail is first checked by employees at the mailroom to assess the regional unit it

Table 3: Involvement of stakeholders in a simulation study for different change management programs

problem owner

TQM/JIT decision maker

analyst

problem owner

BPR/PI decision maker

analyst

(1) problem form. (2) setting objectives (3) conceptualization (4) data collection (5) model translation (6) verification (7) validation (8) experimentation (9,10) evaluation/runs (11) report (12) implementation

0-7695-2056-1/04 $17.00 (C) 2004 IEEE

5

Proceedings of the 37th Hawaii International Conference on System Sciences - 2004

Table 4: Collaboration and simulation for the mail logistics case

Collaboration (1) problem formulation (2) setting objectives (3) conceptualization (4) data collection (5) model translation (6) verification (7) validation (8) experimentation (9,10) evaluation/runs (11) report (12) implementation

problem owner

decision maker

(employees)

(general management)

analyst

individual interview interview

individual group session individual

belongs to. After routing to the regional unit, it is reexamined by the preprocessor of the unit to assess the team to which it belongs. The goal of the project, as formulated by the general management of DIC, was to analyze the logistic processes and assess the bottlenecks within these processes, to finally arrive at possible improvements for these processes. In individual discussions with the general management, employees of the mail room and of the regional units, and the analysts, the objectives of the project were set. Important performance indicators that were identified are: back-log levels, throughput times, failure rates, and process costs. The analysts used interviews with employees of the mail room and the regional units to conceptualize the problem and collect data. Based on this, the analysts constructed and verified the simulation model. The model was validated with employees of the mail room and the regional units. A collaborative session with employees of the mail room and the regional units, the analysts, and several managers was organized about possible improvements. The collaborative session was based on the results of the

model and supported by group support facilities. The group session resulted in several alternatives which were implemented in the simulation model by the analysts. The results were reported back to the general management. In table 4, we present the simulation steps that were carried out and the stakeholders that were involved in each of the steps.

4.2 Redesign of a Dutch cargo handler A Dutch airline handles about 621,000 tons of cargo and mail every year. The cargo flows have increased over the last years and the question was raised by the management whether the home-airport of the airline was a big enough hub to handle future cargo flows. Besides this, the home-airport has plans to restructure and expand the airport, which would force the airline to move to another location at the airport. This led management of the airline to start thinking about the future. The project was started to give the management insight into future options for cargo handling and its consequences. The objectives of the project were set by the analysts, mainly because the management team did not want to

Table 5: Collaboration and simulation for the air cargo case

Collaboration (1) problem formulation (2) setting objectives (3) conceptualization (4) data collection (5) model translation (6) verification (7) validation (8) experimentation (9,10) evaluation/runs (11) report (12) implementation

problem owner

decision maker

(operational+shopfloor)

(management team)

analyst

interview interview

group session individual group session group session

0-7695-2056-1/04 $17.00 (C) 2004 IEEE

6

Proceedings of the 37th Hawaii International Conference on System Sciences - 2004

combine simulation and collaboration to solve the problem. Subsequently, the analysts interviewed operational managers and people on the shop floor to conceptualize the situation and collect data. The analysts constructed and verified the simulation model. The model was validated in a collaborative session with analysts and operational managers. After this, the management team was confronted with the model in a collaborative session. The management team was very enthusiastic and their reservation to integrate simulation and collaboration vanished. However, before they were going to base their decision making on the model, they wanted a thorough validation of the model. The analysts, therefore, presented the results of the model to people on the shop floor. After this validation, the simulation results were taken to a collaborative session with the management team. Again the management team questioned the validity of the model, as some results were not according their expectations. It was decided to conduct an extra validation step by two members of the management team. The model was validated and the management team finally trusted the simulation results. In a final collaborative session with the management team, strategies for the future were designed and implemented in the simulation model by the analysts. The results led to a discussion on which strategy to choose. In table 5 we present the simulation steps that were carried out and the stakeholders that were involved in each of the steps.

5. Discussion and conclusion The case studies described are examples of different change management programs. The case on the mail logistics is closely related to TQM and JIT. The case focused on small improvements in the logistic processes of the mail handling with strong attention for performance indicators. The air cargo case is closely related to BPR and PI. The complete redesign of the cargo handling processes was the objective of the project. In the process of searching for alternatives there was a strong focus on information technology. And creating understanding for the decision makers was a very important aspect in the project. In both cases simulation showed to have added value. It supports in creating understanding and in comparing the outcome of different alternatives. Furthermore, the cases showed that collaboration is a vital part of change management programs. Collaboration was more important for the air cargo case (BPR/PI) than for the mail logistics case (TQM/JIT). In the air cargo case, involvement of the decision makers was greater, which increased the number and intensity of collaborative activities. From this, and from the theory presented in section 3, we conclude that there indeed is an increasing need to integrate simulation and collaboration. Of course, this conclusion is based on

two cases only and further research is needed to see whether the conclusion holds for different situations as well. Although integration of simulation and collaboration is important, the case studies also show that this is difficult in practice. There are many tools available that support simulation and many tools exist to support collaboration. A true integration of these tools, however, does not yet exist. The lack of a true integration leads to inefficiencies in the change management programs, such as long waiting times for stakeholders until the analysts updated the simulation model and until the results are available. Future research should concern the development and evaluation of collaborative simulation tools to overcome these inefficiencies.

Acknowledgement All cases described in this paper were carried out by researchers from the Department of Systems Engineering at the Faculty of Technology, Policy and Management of Delft University of Technology. We are indebted and grateful to the individual researchers that were involved in the cases reported in this paper: Daan van Eijck and Rachid Maghnouji.

References [1] Banks, J., J.S. Carson, B.L. Nelson, and D.M. Nicol, Discrete-Event System Simulation, Upper Sadlle River, New York: Prentice Hall, 2000 [2] Carr, D.K. and H.J. Johansson, Best Practices in Reengineering: What Works and What Doesn't in the Reengineering Process, McGrawHill, New York, 1995 [3] Coyne, K.P. and R. Dye, ‘The Competitive Dynamics of Network-Based Businesses’, Harvard Business Review, JanuaryFebruary 1998, p99-109 [4] Crosby, P.B., Quality is Free, McGrawHill, New York, 1979 [5] Currie, W.L., The Global Information Society, Wiley, Chichester, 2000 [6] Currie, W.L. and V. Hlupic, ‘Simulation Modeling: The Link Between Change Management Approaches’, in: V. Hlupic, Knowledge and Business Process Management, Idea Group Publishing, United Kingdom, 2003, p33-50 [7] Davenport, H., Process Innovation: Reengineering Work Through Information Technology, Harvard Business Press, Boston, MA, 1993 [8] Davenport, T.H. and Stoddard D.B., Reengineering: Business Change of Mythic Proportions, MIS Quarterly, vol. 18, no. 2, 1994 [9] Dean, D.L., J.D. Lee, R.E. Orwig, and D.R. Vogel, ‘Technological Support for Group Process Modeling’, Journal of Management Information Systems, vol. 11, no. 3, 1994-1995, p43-64 [10] Deming, W.E., ‘Improvement of Quality and Productivity through Action by Management’, in: National Productivity Review, 1982, p 12-22 [11] Dennis, A.R., G.S. Hayes, and R.M. Daniels, ‘Business Process Modeling with Group Support Systems’, in: Journal of

0-7695-2056-1/04 $17.00 (C) 2004 IEEE

7

Proceedings of the 37th Hawaii International Conference on System Sciences - 2004

Management Information Systems, vol. 15, no. 4, 1999, p115142 [12] Dennis, A.R., T.A. Carte, and G. Kelly, ‘Breaking the Rules: Success and Failure in Groupware-Supported Business Process Reengineering’, Decision Support Systems, vol. 36, no. 1, 2003, p31-47 [13] Donaldson, L. ‘The Normal Science of Structural Contingency Theory’, in: S.R. Clegg, C. Hardy, and W.R. Nord (eds.), Handbook of Organization Studies, Sage Publications, London, 1996, p57-76 [14] Eden, C. and F. Ackerman, Making Strategy: The Journey of Strategic Management, 1998 [15] Eijck, D.T.T. van, Designing Organizational Coordination, Dissertation, Delft University of Technology, the Netherlands, 1996 [16] Grohowski, R., C. McGoff, D. Vogel, B. Martz, and J.F. Nunamaker jr., ‘Implementing Electronic Meeting Systems at IBM: Lessons Learned and Success Factors’, in: MIS Quarterly, vol. 14, no. 4, 1990, p327-345 [17] Hammer, M., ‘Reengeneering Work: Don’t Automate, Obliterate’, Harvard Business Review, Nov/Dec 1990, no. 4, p104-112 [18] Hammer, M. and J. Champy, Reengineering the Corporation: A Manifesto for Business Revolution, Nicholas Brealy Publishing, London, 1993 [19] Juran, J.M., ‘The Quality Trilogy’, in: Quality Progressi, August 1986, p19-24 [20] Land, F.F., ‘The New Alchemist: or How to Transmute Base Organizations into Corporations of Gleaming Gold’, in: Journal of Strategis Information Systems, no. 5, 1996, p7-17 [21] Markus, M.L., ‘Paradigm Shifts –E-Business and Business/Systems Integration’, in: Communications of the Association for Information Systems, vol. 4, November 2000 [22] Nunamaker jr, J.F., A.R. Dennis, J.S. Valecich, D.R. Vogel, and J.F. George, Electronic Meeting Systems to Support Group Work, Communications of the ACM, vol. 34, no. 7, 1991 [23] Nunamaker jr, J.F., R.O. Briggs, D.M. Mittleman, D.R. Vogel, and P.A. Balthazard, ‘Lessons from a Dozen Years of Group Support Systems Research: A Discussion of Lab and Field Findings’, Journal of Management Information Systems, vol. 13, no. 3, 1996, p163 [24] Paul, R.J., V. Hlupic, and G. Giaglis, ‘Simulation Modeling of Business Processes’, in: D. Avison and D. Edgar-Neville (eds.), Proceedings of the 3rd U.K. Academy of Information Systems Conference, Lincoln, U.K.: McGraw-Hill, 1998 [25] Paul, R.J., G.M. Giaglis, and V. Hlupic, ‘Simulation of Business Processes: A Review’, in: American Behavorial Scientist, vol. 42, no. 10, 1999, p1551-1576 [26] Post, B.Q., ‘Building the Business Case for Group Support Technology’, in: Proceedings of the Hawaiian International Conference on System Sciences, IEEE Computer Society Press, 1992 [27] Pourdehnad, J. and P.J. Robinson, ‘Systems Approach to Knowledge Development for Creating New Products and Services’, in: Systems Research and Behavioral Science, vol. 18, no. 1, 2001, p29-40 [28] Rockart, J.F. and J.E. Short, ‘IT in the 90s: Managing Organizational Interdependence’, in: Sloan Management Review, 1989, p7-17 [29] Short, J.E. and N. Venkatraman, ‘Beyond Business Process Redesign: Redefining Baxter’s Business Network’, in: Sloan Management Review, 1992, p 7-21

[30] Tyran, C.K., A.R. Dennis, D.R. Vogel, and J.F. Nunamaker, ‘The Application of Electronic Meeting Technology to Support Strategic Management’, MIS Quarterly, vol. 16, no. 3, 1992, p313-334 [31] Venkatraman, N. And J.C. Henderson, ‘Real Strategies for Virtual Organizing’, Sloan Management Review, Fall, 1998, p33-48 [32] Vreede, G.J. de and A. Verbraeck, ‘Animating Organizational Processes: Insight Eases Change’, in: Journal of Simulation Practice and Theory, no. 4, 1996, pp245-263 [33] Wanninger, L.A. and G.W. Dickson, ‘GRIP- Group Requirement Identification Process’, in: R.H. Sprague, Proceedings of the Hawaiian International Conference on System Sciences, IEEE Computer Society Press, Los Almitos CA, 1992

0-7695-2056-1/04 $17.00 (C) 2004 IEEE

8