Business Process Re-Engineering with Groupware · Proceedings of the 28th Annual Hawaii...

Proceedings of the 28th Annual Hawaii International Conference on System Sciences ‘- I995

Business Process Re-Engineering with Groupware

Alan Dennis’ Robert Daniels2 Glenda Hayes2 Gigi Kelly’ Dave Lange3 Lawrence Massman

1. Department of Management, Terry College of Business University of Georgia, Athens, GA 30602 2. School of Computer & Information Sciences University of South Alabama, Mobile, AL 36688

3. Automated IS Directorate U.S. Army Missile Command, Redstone Arsenal, AL 35898

Abstract This paper presents a groupware-supported approach

for business process re-engineering. Effective re- engineering must balance data gathering, study, creativity exercises, problem solving, resource allocation, and design, so there is a need for a variely of tools and techniques to be productive. Our experiences in a series of three case studies show the use of groupware saved money in the re-engineering project itself; and the resulting re-engineered processes continue to save money over the years. Groupware enabled widespread participation in a vety rapid redesign process, enabling senior and middle managers to redesign their own cross-functional and cross-business unit processes, leading a greater acceptance of the changes. The methods and tools have been successfully transferred to these organizations, who continue to use them with little assistance of external consultants.

Introduction

Business process re-engineering is the radical redesign of business processes to simplify work and improve performance. Re-engineering is one way that information technology (IT) departments can ensure they are meeting current business needs, as well as having signitlcant positive impacts on the bottom line. However, re- engineering is problematic; as many as 70% of all re- engineering projects fail [7].

This paper describes a groupware-based re- engineering approach that has been successfully adopted by three different organizations: the U.S. Army Installation Management, Flagstar (a multi-billion dollar food service company), and DOD Battlefield Logistics. We are excited about this approach for four reasons. First, it has been used successfully; re-engineered processes and supporting IT have actually been implemented saving millions of dollars. Senior executives and project leaders in these organizations believe that the use of this groupware approach was key

to their success. Second, the approach appears to be repeatable and applicable to variety of organizations and business processes. Third, the reengineered processes were developed jointly by senior management and middle management, leading a greater acceptance of the changes. Finally, the methods and tools have been successfully transferred to these organizations, who continue to use them with little assistance of external consultants.

The re-engineering approach and supporting tools

Re-engineering requires a group effort, because no one individual has sufficient information and expertise to completely understand and improve any truly important business process. Key business processes often cut across departmental lines [2], requiring cross-fimctional teams with representatives from each department. The problem with traditional re-engineering team meetings is that only one person can speak and be understood by the team at one time. Participants must take turns speaking and those not speaking are blocked from contriboting ideas and information until they can find a break in conversation. Participants who are blocked from contributing ideas may forget or suppress them because they seem less relevant or less original later on [4]. A few participants often dominate, so key information is often overlooked [ 121.

Groupware

One approach to reducing these problems is the use of groupware (see Jessup & Valacich, 1993 for a full discussion about groupware). With the form of groupware used in this study, group members worked together in the same room at the same time and used computers to interact and exchange ideas, instead of and in addition to, discussing ideas verbally. This form of groupware provides a package of three components [lo].

376 1060.3425/95$4.0001995 IEEE

Proceedings of the 28th Hawaii International Conference on System Sciences (HICSS '95) 1060-3425/95 $10.00 © 1995 IEEE

Proceedings of the 28th Annual Hawaii International Conference on System Sciences - 1995

The first is a meeting room that provides networked computer workstations to all participants, plus a large screen video projection system that acts as an electronic blackboard. The second is special purpose software that enables participants to communicate, propose ideas, analyze options, evaluate alternatives, and so on. The third component is the facilitator whose role may include assisting in agenda development, chairing the meeting, and helping participants to use the technology.

ideas, builds a model of the new (“to-be”) processes, and then rapidly prototypes and pilot tests the processes and supporting IT [ 51.

Groupware provides at least three functions that may improve meetings: 1) parallel communication; 2) anonymity; and 3) group memory [lo]. In a traditional meeting, if 10 subject matter experts participate equally in a one hour meeting, each expert spends six minutes contributing information and 54 minutes listening (or at least not contributing). Parallel communication enables all participants to contribute information, ideas, and opinions simultaneously so that information is collected much more quickly.

Anonymity may improve meetings by separating personalities from the problem. Individuals, particularly low status or low ranking participants, may withhold ideas due to the apprehension of negative evaluation of ideas. Participants may also feel a pressure to conform to the group majority or more senior participants, whether that pressure is intended or not.

Business process modeling: The process modeling technique used was IDEFO, a technique based on the SADT technique [ 1 l] originally developed in the 1970’s, which has since been refined for use in the DOD’S re- engineering efforts [I]. The fundamental building block of an IDEFO model is an activity. Each activity in the overall business process has 1) a number; 2) a name; 3) a short definition; and, 4) a set of Inputs, Controls, Outputs, and Mechanisms (ICOMs) that define how the activity interacts with other activities and entities outside the model, This is often presented graphically as a context diagram with the text definition as a backup report. Inputs and Outputs are self-explanatory -- the information and things that the activity receives and produces. Controls are items that guide how the activity is performed (e.g., policies). Mechanisms are resources used to perform the activity (e.g., people). In general, every activity has at least one input, one control, and one output, with a preferred maximum of six inputs, six outputs, six controls, and six mechanisms per activity [5].

A group memory is provided by electronically recording information entered into the system. Participants can independently review each other’s contributions. The participants can de-couple themselves from the data input process, read other’s comments, pause, think, and then rejoin the discussion. By enabling participants to shut the world out and concentrate on the comments of others, the opportunity for “process gains” from synergy and learning should increase.

IDEFO is a hierarchical modeling technique in which activities are decomposed into sub-activities (also called “children”), which in turn are decomposed into sub-sub- activities (also called “grandchildren”) and so on. Activity numbers indicate the level of decomposition. Activity 1.1 (also called Al 1) is the child of activity Al. Activity All1 is a child of All, and so on. A list of activities and their children is called an “activity tree.” ICOMs can be decomposed in a similar manner.

Tests of groupware for information capture and idea generation have been very promising. Initial laboratory experiments have found that using groupware, groups can generate substantially more information and ideas of higher quality in a given amount of time than non- groupware groups [6,13]. Field studies at IBM, Boeing, and others suggest similar improvements in the quantity and quality of idea and information generation [3 $1.

The approach for building an IDEFO model with groupware has three steps. First, the entire group discusses the overall business process (called AO) and identifies a set of 3-6 high-level activities (Al-A6), using a chauffeured process: the group verbally discusses the activities and the facilitator records the key points using a groupware modeling tool (described below).

A re-engineering methodology

There are many approaches to re-engineering, most of which share many common aspects. The approach used in this project was that of the U.S. Department of Defense (DOD) and is typical of approaches used by other organizations. It has four steps: a group of experts first builds a model of the current (or “as-is”) processes, analyzes this model by generating a set of improvement

Second, the group of experts is divided into subgroups of 3-5 members based on their interest and expertise. These subgroups decompose the high-level activities and write their definitions . For example, one subgroup may work on activities Al and A2, while another does A3. Subgroup members work together, using a cluster of workstations, developing their portion of the model.. Although everyone can see the work done by other groups, experts only alter their assigned sections (enforceable through the software). The facilitator(s) acts as a coach -- providing advice about guidelines and the style of the model. Subgroups work top-down, decomposing higher level activities into lower ones.

379



Once all the subgroups have finished decomposing and defining the activities, the entire group reconvenes to discuss the expanded model. Each participant individually reviews all the activities and definitions and uses an electronic brainstorming tool to make comments about the model (see Gallupe et al., 1992; Nunamaker, et al. 1991). Participants identify critical issues that the group as a whole needs to discuss and resolve, as well as minor issues such as spelling and wording that needs little discussion. Critical issues are discussed verbally by the entire group. Minor issues are simply printed and given to the subgroup responsible for that part of the model. Each subgroup then revises the part of the model it is responsible for, based on the group consensus.

The third step is to develop the ICOMs. Once again, subgroups take initial responsibility for one or more high level activities, which are then discussed by the group as a whole. Experts are encouraged to work bottom-up (ICOMS at the lowest level in the activity model first) in defining the ICOMs. ICOMs are defined bottom-up because it is the ICOMs at the bottom of the model that represent “real” things (forms, policies, people). ICOMs attached to higher-level activities are simply aggregations

or abstractions of actual things. It has been our experience that experts with little prior IDEFO modeling experience find it easier to provide details first and then abstract them to higher level entities, rather than deriving the details from abstract concepts.

Redesign: The fundamental objective of redesign is to rethink how the business process is performed. We encourage the redesign group to look at the business process model from many different perspectives. Von Oech (1983) identities two basic approaches to idea generation. The first, “soft thinking,” is highly creative, non-rational, open-ended, and ambiguous. The second, “hard thinking,” is logical, rational, analytical, and precise. We normally begin with soft thinking followed by hard thinking, because soft thinking is more open- ended. Once the group of experts has become closely focused on the IDEFO model, as occurs during hard thinking, it becomes more difficult to move them to more open-ended creative thinking. Table 1 summarizes some of the redesign techniques we use.

Table 1



To-be modeling: The next step is to develop an IDEFO To-Be Process model that can be used for further analysis of job responsibilities and to identity the IT required to support the new processes. This is done is the same manner as the As-Is model above. Although the modeling mechanics are the same, this phase is usually more difilcult because the process often continues to evolve as modeling takes place.

goals, with little thought to the impacts on the overall shared process. This case presents an example of how the DOD reengineered a series of processes that spanned as many as 17 different departments.

Prototyping: Usually, the new processes require some IT support. This IT support is rapidly prototyped using some advanced application development tools (e.g., Ace Technologies, Power Builder), and pilot tested in several areas of the organization before being fully implemented.

The management of the many Army, National Guard, and Reserve installations in the U.S. and worldwide is complex. In 1991, the Army employed 250,000 people and spent $5 billion to manage its installations. The manner in which activities were performed differed widely with many unique IT systems, The costs of maintaining these many separate systems and for retraining transferred soldiers in the different processes used at different installations was considerable.

Groupware tools

The groupware software platform used in the DOD and Army projects was GroupSystems, while VisionQuest was used in the Flagstar project. These are general purpose tools to support idea generation, idea organization, and voting. They have been described in depth elsewhere, see Nunamaker et al. ( 199 1) and Nagasundaram and Wagner (199 1).

The objective of the Installation Support Modules (ISM) project was to develop a standard set of business processes and IT that could support both the standard installation activities required by regulations, yet be flexible enough to support any local requirements instituted by the installation commander.

Our initial trials found the these packages lo be helpful, but lacking the needed structure required for business process modeling; therefore, we developed a groupware tool to support the structured modeling of the IDEFO methodology. Initially enforcing the structure required by the modeling technique is more effective than attempting to impose structure on the less structured data collected using standard groupware tools.

Nine basic processes were selected: orders’ management, records management, civilian personnel management, education management, training and audio-visual management, master schedule of activities, drug & alcohol, garrison commanders’ o&e, and, perhaps most importantly, in- and out- processing. In- and out-processing occur when soldiers are transferred from installation to installation or otherwise depart or arrive at an installation. Given that typical postings last three to five years, 20-30% of Army personnel in-process and out-process each year.

The groupware process modeling tool follows a text-specification, graphics-generation approach. All activities and ICOMs are defined using text forms. On demand, the software creates decomposition diagrams of selected activities and their ICOMs. The diagram is displayed on the screen and a hard copy can be printed. The graphic display provides a quick aid to participant understanding, but does not permit participants to graphically edit the model.

The project began with an initial nine week non- groupware meeting to establish the key processes in installation management and to begin constructing a high level IDEFO As-Is model. This proved difficult to do using traditional IDEFO methods. It became clear that there were important variations between installations and commands. Furthermore, broader representation was needed.

Case studies

U.S. Army Installation Management

One common challenge faced by re-engineering teams is the redesign of cross-functional processes [2] -- processes that cut across departmental boundaries. In many cases, each department has developed its own sub-processes and IT support that maximize its own

To overcome the initial problems, project management developed a general approach, which used of groupware, for reengineering each business process . Many of the commands and installations had IDEFO As-Is models of their existing processes. The project leaders decided to forgo building several As-Is models and instead focused solely on redesign and building one To-Be model. Participants were encouraged to bring their As-Is models, where available. In general, 18-22 subject matter experts (enlisted ranks and officers) drawn from all major Army commands participated in each meeting.

This project began in early 1990, with an initial schedule of one process per month. However, the project was interrupted by Operation Desert Storm, so

381



the re-engineering activities were not finished until mid-1991. The meetings were held in groupware meeting rooms at the University of Arizona and Redstone Arsenal in Huntsville, Alabama. Each re- engineered process followed a similar path. Once the To-Be model was completed and approved by its functional proponent, it was circulated to all major commands for acceptance. Once accepted (most with minor changes), a prototype information system was rapidly developed to support the new process. A set of 12 test bed sites were selected for functional validation. In most cases, only a few additional fbnctionalities were identified, but in some cases, several significant new iimctionalities were added. As of May, 1994, seven of the nine new installation processes and information systems were being installed at 28 installations, with the remaining installations scheduled to be converted by 1995.

Space precludes a description of all the processes modeled, so we will briefly describe in- and out- processing as an example. In-processing consists of updating the installation’s records with information provided by the incoming soldier, while out- processing consists of updating the installation’s records and providing the soldier with a ‘packet of information for establishing records at the next installation. By regulations, there are 17 separate functional departments with whom the soldier must interact on in-processing and 15 on out-processing (e.g., ID card station, medical, dental, security clearance). Each installation may also require additional steps in the process (e.g., ensuring receipt of all borrowed items from the recreation center).

In 1990, soldiers typically spent three to five days to in-process and three to tive days to out-process, traveling around the installation to each of these offices. Since not all installations had computer systems (or compatible computer systems), most information was transferred on paper records, although a standard Army-wide information system provided access to some basic information (which in some cases required 1-2 days to access for each data request). The soldiers’ records were retyped at each installation, either into manual files or computer systems maintained separately by each of the 17 areas (which did not share data). Soldiers provided the same basic information (e.g., name, rank, SSN) to each of the 17 areas, requiring significant time to collect and re-type into each system, and making record maintenance quite difficult.

The new process has established a central in- and out-processing office on the installation that houses representatives from all 17 functional areas. There is one central data base shared by all areas, so that the

soldier provides the common information only once. Each functional area still collects and maintains its unique information, but any information needed by more than one area is treated as common data and collected and stored only once. In- and out-processing now requires one day.

The costs (e.g., new hardware and software) associated with this new redesigned process was approximated $200 million. However, the cost savings of these reengineered processes have been significant. Based on a detailed functional economic analysis conducted by the Department of the Army, the re- engineered in- and out-processing alone will save an estimated $400 million in terms of direct out-of- pocket costs avoided by the new processes. The person-days saved due to the new processes adds an additional $54 million per year in cost reductions presuming that the time saved is put to productive use. The indirect benefits of these improved processes (soldiers not having to wait, increased availability and accuracy of information, ease of maintaining records) are also important.

The cost and time savings from using the groupware for re-engineering rather than continuing with the manual effort were also non-trivial. The groupware-based reengineering agendas for each of the nine processes lasted one week at a cost of about $40,000 (total $400,000); the non-groupware agendas developed prior to adopting groupware were each four weeks in length at a cost of $120,000 ($1.2 million). Colonel Wayne W. Byrd the ISM Project Manager (January 1989-April 1993), also estimated that groupware use cut the overall time from project initiation to implementation of the re-engineered processes and supporting IT by 50%.

Flagstar Business Communications

A second challenge often faced by re-engineering teams is the redesign of key organizational processes that are “owned’ by one functional area, but whose design and cost is driven by the actions and processes of many other functional areas. Flagstar Corporation is a multi-billion dollar food service company that operates about 2000 Denny’s, Hardee’s, Quincy’s, and El Poll0 Loco restaurants. The primary focus of Flagstar’s corporate management is information communication with its four restaurant concepts. Since mid 1993, Flagstar has been engaged in several re-engineering projects that will signiticantly change the way in which it interacts with the restaurants it operates. The goal of one project was to re-engineer the business communication process (e.g., mail,

332



reports, invoices, payments). While not particularly “glamorous,” these processes are at the very heart of the corporation and critical to overall success. These processes are operated by one administrative department, but are dependent upon the actions of other functional areas.

A project team of eight core members from the re- engineering group and the mailroom was formed and began by building an IDEFO As-Is model using a groupware room at Flagstar. Once the model was complete, the team began investigating the processes in more detail. One part of the team spent one week examining the mail leaving headquarters, and interviewing key managers and their support staff On average, every day 100 overnight packages and 30,000 pieces of mail entered or let7 the headquarters building, of which 60% were invoices.

Another sub-group investigated the amount of space used to store the paper-based records of business mail, and the amount of paper discarded per day. The equivalent of two entire floors in the headquarters building (14,500 square feet) was used for paper storage. Sixteen tons of paper was discarded every month. Others performed a cost analysis of copying records and mail, and of paying suppliers and employees by check rather than electronic funds transfer (EFT) .

All members of the core team then together performed problem analysis: identifying current problems and then solving them. This was followed by breaking assumptions, future thinking, and technology analysis. These activities resulted in a large set of potential improvement opportunities, including short term incremental actions and longer term, more radical changes.

The next step was to seek wider participation from corporate management and the individual restaurant concepts. Flagstar’s groupware room was small (eight workstations), so to accommodate the wide participation needed, the team then designed a standard 2-3 hour agenda for a series of meetings with the representatives from key areas in the corporation (a same-place-different-time approach in groupware terminology: see Jessup & Valacich, 1993). This agenda included problem analysis, future thinking, and technology analysis. Nine groups participated: marketing, IT, finance, key administrative assistants, selected restaurant general managers, and the senior executive teams of the three restaurant concepts: Denny’s, Hardee’s, and Quincy’s.

The initiatives identified by these groups were combined with those of the core team, resulting in a set of proposals submitted to senior management for approval. The proposals included ways to reduce

communication (e.g., changing management processes to give more autonomy to restaurant general managers and regional managers), ways to eliminate paper communication (e.g., EDI, EFT) and ways to manage paper communication (e.g., optical imaging).

The proposals are in the approval process, and the core team is beginning to build an IDEFO To-Be model of the new processes. Under the current plan, the proposals, once approved, will be phased in over 6-9 months. The net effect of these changes, based on a detailed cost analysis, is an annual savings of several million dollars (the exact amount is confidential).

Mr. David Howell, Manger of Information Systems Planning and leader of Flagstar’s corporate re- engineering team, sees the use of groupware re- engineering as “totally successful.” Compared to previous Flagstar re-engineering projects undertaken without groupware, this groupware-based project moved significantly faster. With the groupware tools, “we did in two days what we couldn’t have done in three weeks [without it].” The total costs for the groupware-project (including the startup costs of new hardware, software, furniture, and training) were less than $80,000; excluding startup costs, the direct project costs were less than $35,000. Two more groupware-based re-engineering projects have just begun.

DOD Battlefield Logistics

Another major challenge faced by re-engineering teams is the integration and modernization of common processes between strategic business units. In this era of mergers and acquisitions, many organizations have related business units with similar processes that operate in different ways and use incompatible information systems. The Army and Marine Corps, for example, have similar missions (winning ground wars) but different strategic responsibilities. The Marines are a lightly armed rapid deployment force while the Army is a heavy force designed for high intensity conflict, but both are more frequently required to work together on joint operations. An analogy might be to consider private sector firm with an overnight courier service (e.g., Federal Express) and residential moving service (e.g., United Van Lines) that must seamlessly interoperate.

One key aspect of this interoperability is logistics, the process of planning and executing the movement and supply of operational forces. Current strategy now envisions a “force projection,” where forces begin in the U.S. and are “projected” into the theater of

383



operations (e.g., Kuwait, Somalia), possibly in concert with allied forces. Here, logistics is key to success; forces must be rapidly transported to the theater and supported in place, with little reliance on host nation transportation and logistics infrastructure.

Unlike the installation management project, whose primarily goal was cost reduction through improved processes, the primary goal of this project was to increase war fighting capability. Battlefield logistics processes proved adequate in the war in Kuwait, but three critical issues emerged, First, the logistics processes and supporting information systems within each of the military services had evolved with little integration. There was a total of 2000 separate logistics information systems in use in the DOD; integrating and sharing resources across service or units proved difftcult. Second, of the more than 30,000 containers of materiel that were sent to Saudi Arabia, over 22,000 arrived with inadequate documentation. They had to be unloaded, documented, and re-loaded before being sent to combat units. This significantly delayed force build-up, and had conflict broken out earlier, could have proved disastrous. Finally, the logistics system proved unable to rapidly deliver some critical items (e.g., aircraft repair parts); a small, but significant percentage of some items were sent via Federal Express.

common paperwork, simpler funding allocations, and fewer supply stockage points. The third was the application of advanced technology to provide assured communications (from combat units to national supplies), total asset visibility (the status of all supplies, vehicles, and units, is always known), source data automation (data are captured once at the source), and integrated computer and communications systems (so that systems across commands, services, and units are seamless).

No oRicial estimates are yet available of the cost savings of these re-engineered processes, as a detailed functional economic analysis has not yet been completed. Perhaps the most important benefit of this project is not a cost saving. The improved processes and data standardization will save significant time in execution and significantly improve the interoperability and operational readiness of combat units, something that may prove critical in future conflicts. This was also the first time that this group of “war fighters” were assembled in this type of environment to discuss and educate each other on their views on supporting operations. The groupware environment presented a “democratic” arena that helped build a tightly bonded group of unified commands.

Given the scope and complexity of the logistics process, it was decided that use of groupware was the only practical way to quickly capture the ideas and information from a large number of participants using a DOD approved To-Be modeling procedures. In March, 1993, 60 logistics experts from the Army and Marines spent three weeks in the groupware facility Redstone Arsenal re-engineering the battlefield logistics processes. Two days were devoted to redesign, using problem analysis and future thinking The remainder was spent modeling the new processes. The proposed changes were approved in late 1993 and prototyping of the supporting IT began.

Discussion

In this section, we outline the key lessons learned.

Re-engineering participants

Space precludes a complete description of the recommended changes, which are now in the IT development process. Three key themes emerged from the redesign phase. The first is an integrated set of processes for requesfing and monitoring all classes of supply for all units, in contrast to the current system where different classes of different units are treated differently. The second was a reduction in number of elements in the supply chain. Supplies now must flow through each of four to seven levels in the logistics chain from depot to final customer, each of which has its own stock of supplies and requires separate paperwork and funds transfer. The new vision is a simpler direct ordering and shipping process with

Re-engineering team: If war is too important to be left to generals, then re-engineering may be too important to be left to analysts and external consultants. Re-engineering requires the active involvement of the senior and middle management of the organization, not just those in the IT department. The projects in this study had a functional expert, not an IT expert, as the key project leader. All projects employed a management team approach, where representatives from the major functional areas helped to guide the project, to ensure that the project addressed the needs of the different functional areas. In all cases, the IT department and consultants played a key role as repositories of re-engineering knowledge and helped the team make key decisions. The point here, though, is that line management performed the analyses and made the decisions; the project was not “handed over” to others.

384



Horizontal participation: Getting the right people to participate in the re-engineering activities is critical. Business processes often cut across functional boundaries. All functional areas connected to the process must be represented, to ensure the that re- engineered processes are most effective and can be successfully implemented. “Customers” and “suppliers” must also be actively involved because they will be affected by the changes.

Vertical participation: In most organizations, radical change is not as common as incremental improvement fostered by programs such as TQM. Incremental change often emerges from the bottom of organizations. Workers, and lower and middle management often make suggestions for incremental improvement, but often lack the big picture knowledge needed for radical change. Radical change is otten thrust down from senior management, who typically lack detailed knowledge required to successfully assess and implement the changes.

By definition, re-engineering involves major organizational changes and significant changes to the supporting IT infrastructure, The result for many large re-engineering projects is top down direction, with IT analysts and external consultants leading the charge, conducting the analyses, and advising senior management who rely on their perceptions and years- old-memories of key business processes. This can cause significant problems, both in successful conception of changes and successful implementation by lower level management who have not been part of the discussions.

Groupware can fundamentally change this. By enabling large groups of participants to work together in an anonymous environment, organizations can benefit from senior and middle management working together to identify, assess, and refine both radical and incremental changes in a “safe” environment. Middle management can challenge senior management and senior management can float trial balloons without attribution.

In these projects, senior management became the catalyst, setting vision, opening boundaries, and motivating middle management to enact change. IT analysts and external consultants became facilitators and coaches, advising and training participants on specific techniques and helping to focus and support their efforts. Middle management became the re- engineering core, identifying opportunities and designing new processes; they owned the change, making implementation simpler.

External participation: Benchmarking processes against “best-practice” processes or the processes operated by leading firms can be useful. Even interviews with other firms or industry associations can prove helpful. A more radical approach is the active involvement of non-competing companies in the project. The benefits can be substantial, because outsiders are less bound to the status quo and can draw insights from different experiences.

Methodology

Modeling: The modeling technique used in these studies, IDEFO, proved very useful. It was easy for novices with no prior experience to learn, although understanding ICOMs and ICOM decomposition proved more challenging that understanding activities and activity decomposition. One of the important benefits of lDEF0 is that it is hierarchical. Other techniques require large wall charts to display the entire model, with users losing the big picture by getting lost in the details. With IDEFO, entire models are represented on one sheet of paper, with subsequent pages available to provide additional detail as desired. The big picture, detailed pictures, and text descriptions are always available depending upon what viewpoint the users wish.

One of the debates within the reengineer@ community is the costs and benefits of building an As- Is model. Some authors advocate little or no modeling for radical change (e.g., Davenport, 1993; Hammer, 1990). We place value on the communication and sharing that occurs during the model building process. This shared learning may be as important as the model that is built, although we don’t go so far as to advocate throwing the model away once it is done.

We also believe it is important to use groupware for modeling, due to the significant performance improvements possible. One study found groupware use to improve modeling productivity by 500% [3]. Such cost savings make justifying an As-Is model much easier. In the battlefield logistics project, building an As-Is model without groupware cost $3 million and took 1.5 months. In that case, costs and benefits are subject to debate. Groupware-based As-Is modeling at Flagstar took one month at a cost of $10,000. The reduced time and increased understanding from groupware meetings makes it practical for the As-Is model to serve as a foundation of reengineering instead of the source of “analysis paralysis”.

385



Redesign: The case studies illustrate how we have used only a few of the techniques in our tool kit. In each of these projects, the re-engineering team selected a subset of techniques that they believed would prove most useful. Most of the organizations felt more comfortable using hard thinking rather than sofi thinking, perhaps because it was simpler or appeared more focused and productive. Nonetheless, we believe that soft thinking may be the more poweti in generating the innovative ideas that are the foundation of radical change.

In these studies, the most commonly used technique was problem analysis, perhaps because it seems the most important to managers. We personally believe that the most powerful techniques are breaking assumptions and future thinking, with duration analysis and activity elimination close seconds.

Meeting timing: Most of the re-engineering sessions on the two Army and DOD projects in this study were done in periods of concentrated work (e.g., one entire week, which periodically included evening work as well). This was due to the need to include participants from around the world, and to minimize travel costs, all activities were performed in one marathon session. The result was a series of very focused, intense meetings. However, groupware-based meetings are, in general, far more strenuous that traditional meetings. Rather than spending considerable time listening, participants are almost continuously actively engaged in building models, generating ideas, or assessing the work of others. By the end of the meeting, participants were clearly tired.

In contrast, the Flagstar project was conducted over two months. The sessions were again very focused, but the spacing of the sessions helped reduce participant fatigue. This pacing of meetings also enabled participants to deliberate and incubate ideas over a greater period of time -- and to circulate ideas with other members of their organizational unit to gain a broader input. While many participants in the two DOD projects contacted their units by phone to gather additional information and opinions, they lacked the ability to incubate ideas. A project plan that allows time between project steps for ideas to incubate, should produce better results.

Tools and techniques

Groupware use: Our experiences have shown that meetings dominate reengineering projects. Use of groupware to improve meeting productivity can result in significant cost and time savings during the re-

engineering project. The groupware meetings have more parallelism with less talk, are more focused, and can involve more people so less rework is needed due to reactions from the rest of the organization. Groupware makes for a stronger buy-in from the meeting participants and promotes greater consensus. In the case of projects with large groups and many organizational units, the meetings enjoy reduced levels of politics, and participants sell their group’s solution to their departments. Implementation goes more quickly.

The combination of general purpose groupware and a simple but flexible groupware process modeling tool made it possible for large numbers of participants to communicate with each other in a timely manner and gain a shared vision. These visions were then used as building blocks for new designs. Processes and systems designed by cross-functional groups, working to resolve their conflicts on the basis of organizational goals rather than technical or political reasons are likely to be easier to maintain and lead to more efficient and effective organizations.

Distributed work: The need to involve many participants in the re-engineering process suggests the need for a large meeting facility. For the Army and DOD projects, the size of the participating group was constrained to fit the size of the groupware facilities (24 in the first case and 60-70 in the second). The Flagstar facility could only accommodate eight participants simultaneously. Clearly a different strategy was required.

The approach adopted by Flagstar was to rotate the re-engineering participants through the meeting facility at different times, each building on the work of the preceding groups. This ability to enable same- place/different-time meetings is one of the key strengths of groupware. Another option, would have been to permit participants located in other offices to join the meeting electronically, by simply connecting to the network and running the same groupware software. In theory, this could enable a relatively limitless number of participants. The difficulty with this lies in the knowledge and experience of the participants. Here, participants were both novice users of the groupware software, as well as novices in the modeling and redesign techniques. We felt it was critical to provide expert facilitation to answer any questions and reduce any concern participants might have had. However, we believe that for participants experienced with groupware and the re-engineering techniques used, distributed groupware, where

366



participants work at different times in different places will become an important option.

Information integration: This approach encourages groups to break into subgroups to perform some of the modeling. One important lesson is from this sub- grouping, is that while work goes much faster, there is a strong need for commonality of terms, definitions, and frames of reference across these sub-groups. While all sub-groups can immediately see the work of all other sub-groups, the conflicts in terms or frames of reference may not be immediately recognized. Unchecked, this may require considerable rework to standardize terms.

The approach we used was to settle on a few common terms and definitions for key items before the group began and attempt to capture emerging terms soon after they appeared. We told each sub-group that any time they debated a specific term or definition, to inform the facilitators of their conclusions, so they could share the information with other groups. The use of distributed groups would obviously complicate this process.

Summary

These groupware-based re-engineering projects are having significant impacts on their organizations, both in terms of increased effectiveness and reduced costs. These organizations attribute much of their success to the use of these groupware-based techniques, which enabled broad participation by both senior and middle managers. These line managers together redesigned their processes, with the assistance of IT and external consultants (rather than relying primarily on outsiders), resulting in better quality proposals for change that were more widely supported. We believe that this success is repeatable and that these techniques can be applied to a variety of other organizations and types of processes. Perhaps most importantly, the methods and tools have been successfully transferred to these organizations, who continue to use them on other projects with little outside assistance.

The impact on the IT groups has also been significant, particularly at Redstone. Redstone opened the first permanent groupware facility in the DOD, initially one meeting room with 24 computers. Demand has steadily grown, such that Redstone now has four groupware meeting rooms, with two more planned. It has also transferred this groupware expertise by helping numerous other DOD organizations establish their own groupware facilities.

And due to its reengineer@ work, the Redstone groupware facility was recently named a National Reinvention Laboratory under the Vice-President’s National Performance Review Program, which means it will play a key role in national re-engineering efforts in the coming years.

References

[l] AFWAL-TR-81-4023, ZDEFO Function Modeling, Armstrong Laboratory, Wright-Patterson AFB, 198 1.

[2] Davenport, T.H. Process Innovation: Reengineering Work through Information Technology, Harvard Business School Press, 1993.

[3]Dennis, A.R., Hayes, G.S. t Daniels, R.M. “Re- engineering Business Process Modeling,” 27th Hawaii International Conzrence on System Sciences, 1994, IV: 244-253.

[4]Diehl, M. & Stroebe W. “Productivity Loss in Brainstorming Groups: Toward the Solution of a Riddle,” Journal of Persona& and Social Psychology, 53, 1987, 497-509.

[5] DOD 8020. l-M, Functional Process Improvement, US. Department of Defense

[6] Gallupe, R.B. Dennis, A.R. Cooper, W.H. Valacich, J.S. Bastianutti, L. & Nunamaker Jr., J.F. “Electronic Brainstorming and Group Size,” Academy of Management Journal, 1992,35:2,350-369.

[7]Hammer, M. & Champy, J. Reengineering the Corporation, 1993, New York: Harper.

[S]Jessup L.M. L Valacich J.S. (eds.), Group Support Systems: New Perspectives, Macmillan, 1993.

[9]Nagasundaram, M. & Wagner, G.R. “Goal Centered Dialogues: A Process Structuring Model for Group Decision Support Systems,” Proceedings of the 11th International Conference. on Decision Support Systems, 199 1, Manhattan Beach, CA, pp. 195-203

[lOJNunamaker, Jr., J.F., Dennis, A.R., Valacich, J.S., Vogel, D.R., & George, J.F. Electronic Meeting Systems to Support Group Work. Communications of the ACM, 34(7), 1991,40-61.

[ 1 l]Ross, D.T. “Structured Analysis (SA): A Language for Communicating Ideas,” in J.D. Couger, M.A. Colter, t RW. Knapp (Eds.) Advanced System Development/ Feasibility Techniques, NY: John Wiley, 1982, 135-163.

[lZ]Shaw, M. Group Dynamics: The Psychology of Small Group Behavior, 198 1, New York: McGraw Hill.

[13]Valacich, J.S. Dennis, A.R. & Connolly, T. “Group Versus Individual Brainstorming: A New Ending to an Old Story,” Organizational Behavior and Human Decision Processes, 1994, 57,448-467.

[14]Von Oech, R., A Whack on the Side of the Head, 1983, New York: Warner Books.

387


Business Process Re-Engineering with Groupware · Proceedings of the 28th Annual Hawaii...

Documents

Transcript of Business Process Re-Engineering with Groupware · Proceedings of the 28th Annual Hawaii...