Improving the Effectiveness of Business Process Development ...

Proceedings of the 42nd Hawaii International Conference on System Sciences - 2009

Improving the effectiveness of business process development through collaboration engineering: a method for process elicitation Kalle Piirainen, Kalle Elfvengren, Jukka Korpela, Markku Tuominen Lappeenranta University of Technology Department of Industrial Management P.O. Box 20 FIN-53851 Lappeenranta Finland {kalle.piirainen|kalle.elfvengren|jukka.korpela|markku.tuominen}@lut.fi

Abstract Businesses transform and processes are transformed as organizations adapt to a changing business environment. The discipline of business process reengineering has proposed guidelines for this transformation, but the task is still challenging and the risk of failure remains high. Especially group work presents major challenges for process design.. Accordingly, this paper proposes a group support system to support process development. The paper leverages the collaboration engineering framework in designing an artifact to support teamwork in process elicitation. The artifact has been designed at a conceptual level and validated through a business case in a global process industry organization. The case indicates that the method for process elicitation works as intended in the given context. The contribution is a group process for business process development.

1. Introduction Business processes transform and are transformed as organizations adapt to changing situations. Traditional manufacturing companies have been forced to move with the changing environment, which has resulted in a need of tools for business process development. Process management is a natural choice for a management framework for many manufacturing companies, as organizations are accustomed to viewing their actions as processes from manufacturing to management. The general idea is to make management interventions repeatable, but what happens if the system breaks down and the processes do not behave in the intended manner? The apparent answer is process development, more commonly called business process reengineering.

Business process reengineering (BPR) has been a popular tool for the management for some years. The mission of BPR discipline is to offer tools for business development through identification and transform of workflows and processes. BPR consists of radically transforming organizational processes through the optimal use of information technologies to achieve major improvements in quality, performance, and productivity [10] [17]. The literature on the subject is broad, including general discussion, practical advice, and frameworks. Some reviews have not been very favorable, e.g. [24], and many projects have not been successful for various reasons, including lacking planning and execution of BPR activities. The real-world problem specific to this paper is that a manufacturing company has experienced problems in a business process despite some efforts of improving the process. The company is facing challenges with the demand forecasting process. Forecasting accuracy is in a constant focus for improvement and the tools used for supporting the process are being developed to satisfy the user needs more comprehensively. The requirements for the quality of the outcome of the forecasting process are high, as the outcome is used as input to other business-critical processes, like capacity management. What makes the situation peculiar, is that the process performance remains sub-par even though some effort has been put into improving demand forecasting. Thus, the first step before making further attempts to improve the process is to gather data about the demands, experiences and problems from the stakeholders in the process. The case is the demand forecasting process of a process industry company. The main research problem in this paper is to develop a method to engage various stakeholders in a process development or process engineering workshop. The literature review conducted to form the artifact revealed that the existing literature leaves room for

978-0-7695-3450-3/09 $25.00 © 2009 IEEE

1


clear cut methods for process development. Thus, the main objective of the method is to engage a group of various stakeholders with possibly conflicting opinions and objectives to contribute together to the same target. As stated, the objective of this study is to develop, or design, a method or an artifact for business process development. Methodologically the task fits into the realm of design science. The design science approach, based on Herbert Simons work [30], is used widely in information systems research. Design science creates and evaluates information technology artifacts intended to solve identified organizational problems. The principle of design science research is that knowledge and understanding of a design problem and its solution are acquired in the building and application of an artifact [20]. However, design science as such, or e.g. its cousin Systems Design Method [26] offer little in the way of practical advice for a designer about to achieve practical results. The help in this respect comes from the direction of Collaboration Engineering (CE). CE is an information systems research discipline which is committed to designing recurring high valued processes. The basic description fits the task in hand, as developing business processes is a high to moderate value task for the host organization. Judging by the pace of development, the task is likely to recur some time in the not too distant future. The main contribution of the paper is the description of a tested method for business process development. The design artifact aims at engaging a group to identify problems in business processes. The design leverages CE practices to achieve a repeatable and effective group process using a group support system (GSS). The design is validated in a representative case situation with practicing industrial managers. The paper is organized into a total of five chapters. The second chapter after the introduction presents the relevant literature and the theoretical premises for designing the process development artifact. The third chapter presents the conceptualization and the design steps. The fourth chapter documents the case and presents the evaluation of the artifact. The fifth and final chapter discusses the results and presents closing thoughts for the paper.

2. Background and literature Business process redesign or reengineering (BPR) was introduced in the 1990s, with the mandate to improve business performance through changing the processes and workflows to a more efficient configuration which enables more output from the same resources in less time. The starting point of BPR was an article by Davenport and Sort [9], which defined a new management method, Business Process Redesign. Another landmark of BPR was in 1993 with the publication of a book by Michael Hammer and James Champy entitled Reengineering the Corporation: A Manifesto for Business Revolution [17]. The main body of the literature on BPR emerged quite early on, in fact before 1995 [12]. A number of benefits have been attributed to BPR, e.g. increases in productivity, a higher quality of products and services offered, cost reductions and a simplified organizational structure [31][2][7][11]. However, by the beginning of the 2000s, the academic and management communities seemed to lose interest in BPR. Deakins and Makgill have discussed the literature and discovered that little rigorous research, especially on the methods for BPR, was published in their chosen period of literature. They also refer to a widespread dissatisfaction with BPR (p. 119) [12]. They attribute the dissatisfaction to the fact that the literature has been overrun with case descriptions and practitioner notes, and contains a less than suitable amount of serious minded research on organizational factors concerning BPR, issues in implementation and work practices. Dennis et al. [13] bring some insight into the matter by describing four BPR projects. The described cases challenge the idealistic radical BPR propositions, and all the successful cases break the rules of BPR by including middle managers as well as top management, and modeling existing processes, and so on. The article suggests exercising caution in radical BPR, as especially the implementation of radical new processes is not a straightforward task, and the process design from a clean slate takes time, without guaranteeing that the existing problems are solved without introducing new ones. Dennis et al. [13] as well as den Hengst and de Vreede [19] go against the grain in proposing that, beside top management, all process stakeholders are needed for successful process design.

2


Pre-Phase - Objectives and definition of goals - Training for BPR - Indoctrination of participants

Phase I - Elicitation of the process - Process and workflow documentation - Identification of problems

Phase II

Phase III

- Generation of alternative solutions to the problems - Consideration of different levels; strategic, tactical and operation problems - Proposals for solutions

- Decision between alternative solutions - Decision criteria and decision model - Evaluation of alternatives - Act of choice

Phase IV - Implementation of new workflows

Post-Phase - Maintenance of the workflows - Corrections to deviation from the plan - Adapting the workflows to changes - Iterating the workflows to better match the specification

Figure 1. The PAWS method [1][3] Table 1 elaborates on some of the common problems in BPR projects. The recurring theme is that the objectives and the projects are poorly defined, the people involved are not informed, and the process for BPR is inefficient [17][19]. The actual causes of these problems can be various. Starting from selecting the participants in the project, to the organization of the project, to motivation and communication to the participants, one key to the most severe problems would be efficient information diffusion and facilitating commitment to the project. Judging by the literature, many problems experienced during BPR projects seem to boil down to limitations in organizing the projects and problems in group work. This is not the first instance when these shortcomings have been noticed and the literature has introduced some frameworks for facilitating group work in BPR projects. A well argued example of a group work method for BPR is the participatory design methodology PAWS, presented in figure 1. The figure also highlights the effort of this paper with respect to BPR. The motivation in the development of

PAWS is to engage the personnel in BPR as actors instead of being passive subjects to change. Borges and Pino [3] have developed the basic BPR by adding the generation of alternatives and choice as a group activity on the process. In PAWS, identification of the process, gaining insight on the contribution of others, and recognition of problems play the key role. The fundamental requirement for improving a process is to develop a shared understanding on the process and the issues, which is precisely why this step plays a fundamental role in the outcome of any BPR project. Later the PAWS method has been carried over to systems development, as e.g. Mouro et al. [25], who introduce a groupware tool to support the BPR effort. They raise the importance of employee participation and shared understanding as the most important issue in later ownership of the reengineered processes and workflows. Albano et al. [1] continue the track by introducing a proprietary GSS solution, which uses PAWS as a basis, and introduces a GSS tool called Generation of oPtions Support (GPS). Also others [13] [19] have proposed solutions to the challenges in

Table 1. Possible causes for problems in BPR, adapted from [8][27][21][16] Common BPR problems

Factors that may cause problems

Failure to develop a BPR strategy

-

Top management is not dedicated to forming a strategy Politics and emotions get in the way Poor grasp of the problem and poorly defined goals Enterprises do not comply with the fundamental principles of BPR

Lack of needed information

-

Wrong people in the development team The people involved are not informed Groupthink Missing information or people are overloaded with information Incomplete access to necessary external information

Wrong scope

- Scope too narrow or too wide - Unrealistic expectations - Unclear definition of development goals

Taking too long

- The process for BPR is inefficient - Lack of an effective methodology - Too great or too little reliance on new information technology

Inadequate resources

- Lack of sponsorship - The BPR project does not have visible commitment and full support of top management - A multidisciplinary and multifunctional steering committee is not formed and assigned to the project

3


BPR (Table 2) and their answer has been based on groupware or GSS, though they use generic tools. Generally, groupware and GSS have been around for a good while. The overviews on past group support system (GSS) research by Fjermestad and Hiltz [14][15] reveal that most studies on GSS use have been experimental by nature, while studies in the difficult task areas of planning, negotiation, and conflict still remain scarce. As experimental studies are generally simpler than business cases, and study designs in experimental studies are typically deliberately created situations, there seems to be a need for research that can deepen the understanding of using a GSS in realworld business situations. Thus, by choosing a single case study approach we wanted to get an insight into a contemporary phenomenon in the real-life context. Although the contribution of Borges and Pino [3] and later developments are interesting, the main barrier for the casual process engineer is the proprietary nature of the introduced support systems. To lower the barriers for using electronic mediation in BRP, a general use GSS should be a wise choice for a support tool. However, in relatively recent studies, it has been noted that GSS itself has some intrinsic barriers for adoption [4]. Practical experiences have shown that facilitator-driven GSS implementation and one-off tailored process artifacts do not penetrate host organizations sufficiently to support the GSS facilities. The answer for overcoming these barriers may lie in a

late development to the stream of GSS literature, that is, collaboration engineering (CE). The objective for CE is in designing collaborative work practices and processes for high value recurring tasks [6][22]. The practical foundation is the need to design manageable and effective workflows or practices to complete complex, high-valued tasks without the need of excessive facilitation. Kolfschoten et al. [23] also write that Collaboration Engineers seek to codify and package key facilitation interventions on forms that can be re-used by teams that do not have professional facilitators at their disposal. Examining the task at hand, it would seem that CE practices have advantage over traditional GSS support, as BPR quite naturally concentrates on high value tasks. Also, as long as the focus is facilitating BPR in general, not just a particular instance or a project, it is safe to say that the task is recurring, as business requirements, models and thus also the processes change more or less frequently.

3. Design of the BPR tool As stated above, the objective for this paper is to improve the demand forecasting process. Following the PAWS-process, the objectives for process development are clear, but the subsequent phases are not as clear and definitely not as well structured in the present organizational form. The next logical step BPR-wise is

Table 2. Benefits of GSS in the BPR context, expanded from [13][19] Decision making challenges in BPR - The development team should be a heterogeneous group and all relevant divisions should be represented - The development needs should be gathered with a wide scope - The problem areas of the current process in different divisions are not identified commonly

Benefits provided by GSS - As GSS allows large group sizes, the extensive composition of teams is not considered a problem, and thus the ability of the team to share knowledge is greater

-

The development needs and current problem areas are not gathered systematically People participating in the development meetings do not always give comments about development issues or do not participate actively It is important that all key persons from different divisions are committed to the development work

- Differing views of a heterogeneous group can be more fully exploited because of parallelism and anonymity - Because of parallelism, everybody has an equal opportunity to participate in the discussion - Anonymity allows open discussion about sensitive issues: opportunity for equal and active participation and more open communication reduces the groupthink-phenomenon

-

Priorization of the development needs of the target process is hard because the business divisions usually have different opinions about the urgency of development tasks

- Conflicts are easier to avoid - Differing views can be more effectively summarized - Voting results focus the discussion and reveals different opinions quickly; reduces the groupthink-phenomenon - Reduces communication dominance by the few

-

The process development project can easily become a project without a starting or ending point Managing teamwork may become challenging because the difficulties to arrange common meeting time and regular development meetings tend to become non-fruitful and time wasting events

- GSS allows virtual meetings, thus improving the flexibility in group work - Meetings are time efficient, common group work time is used effectively - Automatic documentation

-

-

4


to proceed to identification of problems in the process, and that is precisely the objective for the design artifact in this paper. The basic tasks for process development are clear on the surface as per the PAWS framework, but the design aspects for the BPR workshop artifact have more degrees of freedom. Luckily, the CE literature has provided also some down-to-earth advice for workshop planning. CEMM [29] provides a framework for CE tasks, in this case workshop planning, just the same as PAWS offers guidelines to BPR. The CEMM process proceeds in this paper roughly from requirements elicitation to design validation. Ultimately, the practices and the designed artifact deviate from the core of CE in some aspects, mostly due to practical issues. As a practical benchmark, Harder et al. [18] describe a process for project evaluation in the United States Army. Contrary to general CE principles, their case uses a facilitator, even though the ultimate goal was to develop a process for the review board to be used without facilitation. Harder et al. also bring up the discussion about facilitation by

Introduction, orientation

Gather issues

Clarify, elaborate issues

Evaluate importance

No

Are all the process phases handled Yes

Assess the results

Build consensus

Closing discussion

Figure 2. The workflow in the BPR workshop

expressing their doubts about the use of IS without facilitation in organizations, unless the processes are ingrained in the ways of working and habituation to electronic collaboration is reasonably high. In any case, the case, that is, the process of identifying the problems in a business process, has not been ingrained in the organization, so a natural choice was to facilitate the test workshops. Following the CEMM model, the requirements for the BPR artifact can be derived from the research problem of the paper. The rough objective is to offer a workshop where the participants can be engaged in the BPR process and contribute their knowledge. The more specific tasks for the workshop are 1) identification of problems in a business process, 2) negotiation of priorities for the problems, and 3) proposing solutions for the problems. Activity decomposition was executed in an informal fashion following the facilitation experience in the facilities, rather than using strictly defined thinklets. The session planning and tool selection went hand in hand with activity decomposition. The individual meeting activities were modeled on the basis of the main tasks, the time to execute was determined according to the time available and experience on similar workshops, and they were sequenced in the GroupSystems meeting agenda with appropriate tools. Considering the session agenda in terms of tool selection, an important aspect is which patterns of collaboration are to be achieved during the session. The pattern of collaboration, as described by the CE literature [6] is the basis for tool selection in session planning. Figure 2 illustrates the workflow in the process. The first task is to generate, gather experiences and development needs. The issues are elaborated and clarified through commenting and discussion, to ensure that the group understands the items in the same manner. After generation, the group evaluates the importance of the generated issues through polling. The generation and evaluation tasks are repeated for each phase of the target process. The generation also includes time to gather good practices to be preserved during the BPR process. After collecting the issues in the business process, the group moves on to assess and build consensus on the most important issues. The items from the previous poll are lifted to discussion and are assessed through discussion and further polling, and consensus creation is observed and facilitated as needed. The discussion is also directed on future action at this point to prime the next phase of the BPR process. The workshop ends with discussion, closing thoughts and feedback on the session. The final agenda with timing and the selected tools is described in detail in the next chapter with the detailed case description.

5


Pre-Phase - Define and enter the forecasts

Phase I - Evaluate and analyze the forecasts

Phase II - Finalize the forecast

Phase III - Balance demand and supply

Phase IV - Determine resource allocation

Post-Phase - Measure and take corrective actions

Figure 3. The forecasting process of the case company Design validation was an integral part of planning, as the case presented below was scheduled right from the start of the project. The basic validation was done in a case session described below. As a basic sanity check for the artifact, it can be stated that the objectives for the workshop were clear, the tasks were defined, the tools chosen and the agenda timed based on previous experience, or should we say they were based on tried patterns of collaboration. In this respect, the design process followed the proposed guidelines, although not to the fullest extent. The design followed the procedure and recommendations found in the literature. Overall, the basic criteria for a successful process development workshop should be in order.

4. Case description The findings of the present study are based on the GSS meeting experiences gathered with a global process industry firm. Regarding the BPR task, the objective for the session was to identify problems in the demand forecasting process in the case company. Figure 3 illustrates the existing forecasting process of the company. The illustration is highly aggregated, in the real organization the process is a multidisciplinary effort with multiple contributors and users all around the organization. For each phase of the existing forecasting process, the objectives in the GSS session are to 1) analyze current performance of the target process, 2) define the development needs, 3) prioritize the development needs, and 4) ensure commitment to the development through discussion. The authors used GroupSystems Meeting Room software in the execution of the case. The GroupSystems comprises half a dozen different tightly integrated applications, which support different phases of group processes, such as brainstorming, list building, information gathering, voting, organizing, prioritizing, and consensus building. The GS software represents a typical GSS package well and it has a strong market position in the industry. Another selection criterion was the availability of the facility and previous experiences with the system.

The participants in the test session were managers in charge of the case firms forecasting process. There were altogether nine participants in the GSS meeting. In addition to the participants, two of the authors were present, one as an observer and the other as the facilitator. The observing researcher did not interfere with the process but observed the behavior of the team members actively. The objective of the GSS session was to help the team to make plans and decisions on how to develop the forecasting process. The workshop started with a brief presentation of the system by the experienced GSS facilitator. The GSS process consisted of seven main phases. The results were summarized in the end of the session and feedback of the process was given by the team members. Table 3 summarizes the workshop agenda and activities. The main phase was the second phase which contained a separate discussion for each task in the forecasting process. The team members had a chance to clarify their input during the response time by adding written comments under the opinions if necessary. The answers to each phase were prioritized with voting tools. As for the actual observations: the process structuring feature of the GSS seemed to improve the efficiency of the group work. Because of the parallelism feature of the GSS, the differing views of the team members were more efficiently elaborated than in traditional meetings, thus reducing the classical difficulty of teams to share knowledge. Moreover, it was easier to reach consensus than in the traditional meetings because of the voting tools. The anonymity of the GSS session put all the team members to the same level and nobody prevented the team members from commenting in a truthful manner. Thus, personal relationships or hierarchies within the team did not seem to be a problem. Summing up the observations: the participants worked efficiently after a short period of orientation. The group concentrated on the task and was active in communicating through the system. Also the verbal discussion was lively and the participants generally owned up to their contribution. The overall consensus

6


and ownership of results seemed to be very satisfactory. The meetings were also rated with a questionnaire for comparison with the observations. Meeting satisfaction is an important measure of the effectiveness of GSS technology [5][28]. This is because unless the use of GSS technology produces an increase in meeting satisfaction, it is unlikely that the users will seek to adopt the technology, regardless of any productivity gains that might be realized [28]. According to Briggs et al. [5], there are at least two aspects of a meeting, which a participant could feel satisfaction with: the meeting outcomes and the process by which the outcomes are attained. Accordingly, the participants evaluated the meeting and the GSS process by verbal comments and by filling in a questionnaire at the end of the meeting. The answers were given anonymously, which reduces the effect of the group think -phenomenon and the natural tendency towards pleasing the hosts of the meeting. The survey questions and the answers are summarized in table 4. In addition, there were some open-ended questions about how the process could be done better. Two of the questions evaluated the general meeting satisfaction of the participants: the question Were the results worth the effort spent? evaluated the meeting outcomes and the question How well

were the objectives of the session achieved? evaluated indirectly the meeting process by which the outcomes were attained. The average answer to the question Were the results worth the effort spent? was 8.3 (scale 1 to 10) and to the question How well were the objectives achieved? 7.4. The standard deviation for each question is reasonable small, which indicates that the whole group was satisfied with the workshop. These survey answers indicate good and common satisfaction with the meeting outcomes and a successful meeting process. In addition, the answers to questions 4 and 5 indicate satisfaction with the effectiveness of the GSS process. In addition, there were two questions in the survey about whether the person would utilize the GSS again, and whether he would recommend the GSS for others. The answer options in the questions were simply yes or no. According to the survey, all the nine participants would utilize the GSS again in similar types of situations, and they would also recommend the GSS for other colleagues, which indicate very high satisfaction with the developed process. When asked about the benefits of the GSS compared to other meeting methods, the efficiency of the process was strongly addressed. The GSS session was for example commented as follows: helps in focusing on the essential issues, It was very effective in the sense that it made sure that everybody got they opinion

Table 3. Meeting agenda and timing for the case workshop Meeting phase Pre-planning Introduction - 45 minutes Forecasting process phase 1 - 45 minutes - Categorizer and vote tool Forecasting process phase 2 - 45 minutes - Categorizer and vote tool

Description - Planning of the meeting (Procedure described in chapter 3) - Purpose and agenda of the day - Present state: recognized problem areas - Collecting opinions about the development needs - Collecting opinions about functional practices of the current state: what are we doing well, what works well now? - Choosing 5 to 8 most important needs by voting - Brief discussion about the most important development needs

Forecasting process phase 3 - 45 minutes - Categorizer and vote tool Forecasting process phase 4 - 45 minutes - Categorizer and vote tool Whole forecasting process - 30 minutes - Categorizer and vote tool

- Summary of the results - Plans for further actions

Discussion - 20 minutes - Feedback

- Filling in the feedback form

Input statistics

- 46 development needs and 61 comments - 26 working practices and 37 comments - 15 development needs and 40 comments - 15 working practices and 12 comments - 17 development needs and 29 comments - 19 working practices and 5 comments - 23 development needs and 9 comments - Working practices were not asked about - 28 development needs - Comments and working practices were not asked

7


Table 4. Feedback survey results Survey questions (scale 1 to 10, with 10 the highest value)

Mean (n=9)

std.

1. How well did the session live up to your expectations?

7.9

0.9

7.4

0.7

8.3

1.1

8.1

0.8

7.8

1.6

2. How well were the objectives of the session achieved? 3. Were the session results worth the effort spent? 4. Evaluate the effectiveness of the GSS process 5. How well did the process help in effectively focusing the discussion on essential matters?

heard, and Unbeatable speed in summarizing the comments.

5. Discussion and conclusion The paper presented the research problem of developing suitable tools to support business process reengineering or design. The literature of BPR was used to get a grasp of the challenges for BPR effort. The PAWS framework was used as a reference for BPR. The task of identifying problems in business processes was under special attention in the design effort. One of the main challenges was how to engage a diverse group of experts to contribute to BPR. The solution proposed for the group work was the use of a GSS system. The design of a support system for BPR was done leveraging the principles of CE. The result of the effort was a computer mediated BPR process. To give an answer to the research problem, the design artifact was developed on a general level and to specifically facilitate collaboration in the BPR context. The design artifact concentrated on gathering problems and guidelines for BPR, but a similar tool can be developed for different tasks in BPR. The design was validated with a case study, which confirmed the feasibility of the process. The case chosen was a large company in the process industry. The case workshop was designed carefully beforehand, using existing best practices. Meeting satisfaction and goal attainment were satisfactory to the participants of the case. Comparing the observations and the questionnaire results, it would seem that the data correlate qualitatively, which indicates that positive response bias in the answers is not a great issue. Of course, meeting satisfaction after some time and after analysis of the results is another matter altogether. Generally, one case study restricts the validity of the results. However, the design artifact

incorporates best practices for BPR and collaboration support, and it is not tied to any particular case at the conceptual level. As such, the results do not offer validation for the design outside the case company, but as a proof-of-concept, the results do not show any specific reason why the artifact could not be used in different environments, with proper caution. As explained above, the design procedure leveraged CE practices as a best practice guideline, but not to the letter. This can be seen as a weak point in the effort, but considering that the empirical work is based on one case, this research can be viewed as a proof of concept. In short, this empirical endeavor has proved the feasibility of using the described process in process elicitation, no more, no less. The literature review on BPR indicated that the existing research and practice might leave room for improvement concerning the methods for BPR. The objective was to facilitate group work and goal attainment in BPR, and the emerging CE practice was leveraged to design the method artifact and to achieve better generalizability for the results. Table 2 proposes multiple benefits from using a GSS for BPR, though most of them are condensed in the ability of GSS to facilitate group work. The participants in the group were from multiple organizational disciplines and divisions, and as they were able to reach the goals for the sessions and scored meeting satisfaction as high, this would indicate that at least some of the proposed benefits were in fact reached. Also, the fact that the workshop had predetermined objectives, agenda and active facilitation, speak for the conclusion that use of a GSS improves control over the project. The whole BPR process can be organized to similar workshopsize chunks, and as long as the agenda is followed, the timing, contents and results should be reasonably foreseeable. Beside the fulfilled promises, the effect of an anyplace/anytime meeting was not tested. Although there are some potential benefits, the face-to-face

8


meeting is more suited for method/process development. As also Harder et al. [18] note, the facilitator has more control over the timing and content of the sessions, and the facilitator can correct the meeting structure on the fly if the pre-planned agenda does not work for some reason. A critical examination of the CE principles used in the design is called for. It might be questioned what the contribution of CE is, especially in its informal form. The immediate benefits for an experienced facilitator might not be great, as was the situation also in this case. The detailed planning and facilitation of the session was executed based on previous experience. Still, the situation is different for inexperienced personnel. First of all, the CE literature offers a procedure and a basic checklist for successful session planning, and of course CE also helps in agenda planning and even facilitation. CE has also an additional benefit, as it provides tools for codifying the sessions, which helps in dispersing good practices. It may then be asked, what about the intuitive approach to CE, why was the process not presented in thinklets and did the CE in fact influence the case at all? The answer is that the underlying design logic was picked from CE literature and the workflow was codified to patterns of collaboration, which offers a springboard for further advancement on the subject. Due to the nature of the research problem, the research has mostly managerial implications. The main contribution is the novel design artifact for problem identification in BPR. As for academic implications, the paper can be positioned in the BPR literature, where it adds to the practical methods for executing BPR. As noted, previous research has already addressed GSS in BPR [13][19], but the presented design artifact offers a more specific method for the given task when compared to e.g. the collaborative business engineering approach [19]. On the other hand, the paper also contributes to the emerging stream on CE, where it shows one implementation of the CE principles in workshop design. Further research opportunities rise also from the interaction of BPR and CE. As noted above, the current process should be thinkletisized for further development and validation. As an obvious shortage, the proposed artifact covers only one task in the general process of BPR, and as the group proceeds in improving the process, they will probably need further support. Especially in the present case, GSS could be utilized in action planning and process auditing after the implementation. Overall, the proposed design artifact for identification of problems in business processes worked in the case and satisfied the participants. The research forms a good basis for further improvement

on the artifact and further work on using CE tools for process design.

6. References [1] F. Albano; J.A. Pino and M. R. S. Borges, Participatory business process reengineering design: generating solutions, in the Proceedings of the XXI International Conference of the Chilean Computer Science Society, 2001. [2] R. S., Barton, "Business Process Reengineering", Business Quarterly, 57(3), 1993, pp. 101- 103. [3] M. R. S. Borges and J. A. Pino, PAWS: towards a participatory approach to business process reengineering, in the Proceedings of the String Processing and Information Retrieval Symposium and International Workshop on Groupware, Cancun, Mexico, 1999 [4] R. O. Briggs, G.-J. de Vreede and J. F. Nunamaker Jr., Collaboration Engineering with ThinkLets to Pursue Sustained Success with Group support systems, Journal of Management Information Systems, 19(4), 2003, pp. 31-64. [5] R. O. Briggs, G.-J. de Vreede and B. A. Reinig, A Theory and Measurement of Meeting Satisfaction, in the Proceedings of 36th Hawaii International Conference on System Sciences, 2003. [6] R. O. Briggs, G. L. Kolfschoten, G.-J. de Vreede, and D. L. Dean, Defining Key Concepts for Collaboration Engineering, in the Proceedings of the 12th Americas Conference on Information systems, Acapulco, Mexico. 2006. [7] A. Case, "Business Process ReEngineering, Questions and Answers," Software Engineering Strategies E210-708, Gartner Group 1992. [8] J. Champy, Reengineering Management, Harper Business, New York NY, 1995. [9] T. H. Davenport and J. Short, The new industrial engineering: information technology and business process redesign, Sloan Management Review, Summer 1990, pp. 11-27. [10] T. H. Davenport, Process Innovation: Reengineering Work through Information Technology, Harvard Business School Press, Boston MA, 1993. [11] T. H. Davenport, and M.C. Beers. "Managing Information about Processes," Journal of Management Information Systems, 12(1), 1995, pp. 57-80. [12] E. Deakins and H. H. Makgill, What Killed BPR? Some evidence from the literature, Business Process Management Journal, 3(1), 1997, pp. 81-107. [13] A. R. Dennis, T. A. Carte and G. G. Kelly, Breaking the rules: success and failure in groupware-

9


supported business process reengineering, Decision Support Systems, 26, 2003, pp. 31-47. [14] J. Fjermestad and S. R. Hiltz, An assessment of group support systems experimental research: methodology and results, Journal of Management Information Systems, 15(3), 1998, pp. 7-149. [15] J. Fjermestad and S. R. Hiltz, Group Support Systems: A Descriptive Evaluation of Case and Field Studies, Journal of Management Information Systems, 17(3), 2000, pp. 115-159. [16] S. Guha, W. J. Kettinger, and J.T.C. Teng "The IS Manager's Enabling Role in Business Process Reengineering," Information Management, Report Number 1- 03-10. Auerbach Publications. 1992. [17] M. Hammer, and J. Champy Reengineering the Corporation: A Manifesto for Business Revolution, Harper Business, New York NY, 1993. [18] R. J. Harder, J. M. Keeter, B. W. Woodcock, J. W. Ferguson and F. W. Wills, Insights in Implementing Collaboration Engineering, in the Proceedings of the 38th Hawaii International Conference on System Sciences, 2005. [19] M. den Hengst and G.J. de Vreede, Collaborative Business Engineering: A Decade of Lessons from the Field, Journal of Management Information Systems, 20(4), 2004, pp. 85-113. [20] A. Hevner, S. March, J. Park and S. Ram, Design Science in Information Systems Research, MIS Quarterly, 28(1), 2004, pp. 75-105. [21] W. J. Kettinger, and V. Grover, "Toward a Theory of Business Process Change Management", Journal of Management Information Systems, 12(1), 1995, pp. 9-30. [22] G. L. Kolfschoten and G.-J. de Vreede, The Collaboration Engineering Approach for Designing Collaboration Processes, in the Proceeding of the 13th International Workshop in Groupware: Design, Implementation and Use, 2007, pp. 95110.

[23] G. L. Kolfschoten, R. O. Briggs, G. J. de Vreede, P. H. M. Jacobs and , J. H. Appelman, A conceptual foundation of the thinkLet concept for Collaboration Engineering, International Journal of Human-Computer studies, 64, 2006, pp. 611-621. [24] G. Kruse, Surviving in the jungle, Manufacturing Engineer, 80(5), 2001, pp. 223-226. [25] E. Z. Mouro, M. R. S. Borges and C. R. Garcez, A groupware tool to support participatory business process reengineering, String Processing and Information Retrieval Symposium and International Workshop on Groupware, Cancun, Mexico 1999, pp. 314-321. [26] J. F. Nunamaker Jr., M. Chen and T. D. M. Purdin, Systems development in information systems research, Journal of Management Information Systems, 7, 1991, pp. 89-106. [27] L. Raymond, F. Bergeron and S. Rivard, Determinants of business process reengineering success in small and large enterprises: an empirical study in the Canadian context, Journal of Small Business Management, 36, 1998. [28] B. A. Reinig, Toward and Understanding of Satisfaction with the Process and Outcomes of Teamwork, Journal of Management Information Systems, 19(4), 2003, pp. 65-83. [29] E. Santanen, G. Kolfschoten and K. Golla, The Collaboration Engineering Maturity Model, in the Proceedings of the 39th Hawaii International Conference on System Sciences, 2006. [30] H. A. Simon, The Sciences of the Artificial, 3rd ed., MIT Press, Cambridge MA, 1996. [31] H. A. Smith, and J.D. McKeen "Re-Engineering I.S.: The Experts Look at Themselves," Working paper 9231, Queen's University (September), 1992.

10