current advances in group-supported business process ... · pdf filecurrent advances in...

Proceedings of the 29th Annual Hawaii International Conference on System Sciences - 1996

Current Advances in Group-Supported Business Process Reengineering

Mark 0. Pendergast

Management and Systems Dept. College of Business and Economics

Washington State University Richland, WA

USA

Abstract

Recent studies at the University of Arizona and elsewhere have suggested that an Electronic Meeting System (EMS) designed to support construction of IDEFO models can eflectively support groups during development of semantic models. Group electronic modeling tools enable large groups of Subject Matter Experts (SMEs) from the business areas to actively participate in model building process and to build models signtjicantly faster than traditional modeling methodr. This paper details ongoing research at the University of Arizona concerned with computer supported collaborative model development. Specifically, we will describe recent improvements to our Enterprise Analysis/Activity IDEFO based modeling sofmare. We have taken advantage of object-oriented technology advances and modeling process refinements to improve ftve areas of model construction: graphics creation, ICOM creation, bundle formation, semantic analysis, and group coordination. Graphics were improved by allowing SMEs to quickly generate diagrams at their stations and by integrating diagrams with text and tables in printed reports. ICOM creation and bundle formation operations were enhanced by the addition of intelligent pick-lists and graphical bundle displays. Identtfication of IDEFO semantic violations are visually displayed using t,he red dots in the Viewer and by a semantic analysis engine in the Model Builder which is capable of detecting 28 direrent rule violations. Finally, group coordination has been improved by allowing facilitators to create subgroups of SMEs, freeze portions of the node tree, and improved visual cues. The second generation Enterprise Analysis tool set is currently being evaluated in a number of DOD and industry case studies. To date, the tool set has been successfully used by many groups for development and analysis of models ranging from environmental planning to business travel planning.

Douglas L. Dean, James D. Lee, Boris Nevstrujev, Nina Katie

Center for the Management of Information Management Information Systems Department College of Business and Public Administration

University of Arizona Tucson, Arizona

USA

Introduction

Current business processes are often artifacts of past events and happenstance rather than careful design and alignment with current business objectives [7][8]. Business improvement through business analysis and redesign is not necessarily new [2], although awareness of the need for significant improvements appears to be growing.

Models support conceptualization, communication, analysis, ,and design for development and improvement of business processes and information systems. Models facilitate understanding of the many steps and relationships of business processes. They help business personnel understand the work domain and identify improvement opportunities. Involvement of key personnel during model development and analysis is important for model accuracy as well as for political ramifications. Nevertheless, models have traditionally been developed by individuals and small groups because of the complexity and difficulties involved when larger groups participate in the modeling process. As a result models are developed slowly and with limited, restrictive forms of participation.

Recent studies at the University of Arizona and elsewhere have suggested that an Electronic Meeting System (EMS) designed to support construction of IDEFO models can effectively support groups during rapid development of semantic models [5][3][4]. Group electronic modeling tools enable large groups of Subject Matter Experts (SMEs) from the business areas to actively and productively participate in the model building process.

This paper details ongoing research at the University of Arizona concerned with computer supported collaborative model development. Specifically, we will describe recent improvements to our Enterprise Analysis/Activity IDEFO based modeling software. We have taken advantage of object-oriented technology advances and modeling process refinements

451 1060-3425/96 $5.00 0 1996 IEEE

Proceedings of the 1996 Hawaii International Conference on System Sciences (HICSS-29) 1060-3425/96 $10.00 © 1996 IEEE

Proceedings of the 29th Annual Hawaii International Conference on System Sciences - I996

to improve five areas of model construction: graphics creation, ICOM creation, bundle formation, semantic analysis, and group coordination. The paper begins by reviewing our past Enterprise Analysis research, followed by the details of current changes in architecture and procedures, and concludes with a summary and a brief look at work in progress.

methodologies using a combination of standard Electronic Meeting Systems tools (GroupSystems V Ventana Corporation) and custom designed model definition programs. These programs allow the SMEs to enter activity and data descriptions into relational databases via text forms. (reference figure 1).

Past research

Over the last 3 years, Enterprise Analysis tools developed at the University of Arizona have been geared toward group enabling the capture of a number of the IDEF family of design methodologies. This is an ongoing research program. Some of the findings of this past research and a preliminary glimpse of this technology can be found in [4] and [3]. Since then, this collaborative modeling tool has matured considerably. This paper chronicles this progress.

There are a variety of methods for modeling business processes. The IDEFO definition method is one method commonly used to develop business activity models. This methodology is used to define a functional or activity model of what an organization does. The term “IDEF” comes from ICAM (Integrated Computer-Aided Manufacturing) DEFinition language [ 141. The IDEFO method grew out of the Air Force Integrated Computer Aided Manufacturing project. An IDEFO model consists of an activity hierarchy with the attending constraints on those activities at multiple levels of detail. Activities are bounded by Inputs, Outputs, Controls, and Mechanism, referred to in aggregate as ICOMs. ICOMs show the information and physical objects that link activities. Inputs enter the left of activities, controls enter the top, outputs exit from the right, and mechanisms (or resources) enter fi-om the bottom.

Figure 1 - First generation activity decomposition

IDEFO is one of a family of IDEF methods [ 1 I] that graphically and semantically define organizational and information systems processes. Other members of the IDEF family include methods for relational data modeling (IDEFlx), process flow modeling (IDEF3), object- oriented modeling (IDEF4), and others. IDEFO is based largely on a well-established graphical language known as SADT (Structured Analysis and Design Technique)[ 131 [lo] [ 111. The basic concepts of IDEFO are simple enough to be grasped by non-modeling experts, but developing integrated, parsimonious models is best performed with the assistance of someone who understands the modeling process and the reasons for the IDEFO conventions. IDEFO models are valuable aids both for business analysis and for information systems analysis.

These tools provided a shared work environment that included concurrency control so that only one workstation could edit a specific activity or ICOM at a time and yet individuals could view all activities and ICOMs concurrently. Researchers discovered the importance of enforced look-ups so that only ICOMs in the ICOM glossary could be attached to activities. If an SME tried to attach an ICOM to an activity that was not already in the list, the SME was notified that item was new to the list and could pick an existing ICOM off of the list, or could create the new ICOM in the list. This reduced the number of homonyms and synonyms created in the model. It was also found that restricting the number of attachments of ICOMs to six helps SMEs remember to push details downward in the decompositions were they belonged.

Past generations of groupware tools developed at Arizona implemented the IDEFO and IDEFlx

Finding an appropriate means of providing formal graphics to SMEs during sessions was an iterative process. The first attempt consisted of an analyst/modeler serving as scribe and entering the models into a single- user modeling tool in accordance with the textual content captured in the group tool. Because the models developed so rapidly and were so dynamic, the scribe could not keep up. As a result, there was little real-time feedback to allow for proper visualization and reconciliation of the models. The second method consisted of exporting data from the model editor in a format that could be imported into a commercial IDEF CASE tool. The export routine made it possible to generate a hard copy of the model graphics in 5 to 10 minutes, depending on model size. Though this was a vast improvement over the previous method, it was not without problem. The IDEF CASE tool would automatically leave out parts of the model that

452


were semantically in error, without providing details of the errors. Thus it became apparent that the group environment needed its own graphic generation capabilities.

Finally, a viewer/semantic checker was developed that could generate model graphics at each individual workstation and inform participants of various semantic errors existing in the models. This allowed the participants to invoke the viewer at any time for better visualization of the models and also proved to be a great help in error elimination and model reconciliation.

Both the model editor and the viewer worked on the same data structures. Although the viewer could run on any station it was not possible to toggle directly between the model editor and the viewer. Thus, it was typical to have the viewer working on one workstation next to a different workstation running the model editor. The viewer (graphical component of our tool) was known as the Enterprise Analyzer (EA) Viewer. The initial version of the viewer proved to be rather slow, often taking several minutes to build the graphics at each workstation.


The models compared well on a number of quality indicators to models produced in traditional environments [31*

Opportunities for improvement

Over time, available technology became more powerful and sophisticated, expectations of SMEs increased, and systems being modeled became more complex. It was clear that a second generation of modeling tools was called for. This generation should build on the experience gained from the early prototypes and take advantage of more powerful shared databases and GUI environments. With this new generation of tools we not only aim to improve user interfaces, but improve and extend support for BPR processes themselves. Upon reviewing our existing methods and procedures, we identified five areas where significant advances could be made:

Graphics

Formal and informal graphical representations of the model evolved over the course of the project. Formal graphics are defined as the final structured product (model) in IDEF compliant form that can be used to as input to other phases of business re-engineering. Informal graphics are any sketches, doodles, lists, etc. created by session participants on whiteboards or paper which initiate modeling, illustrate alternative ideas, and/or are used to focus verbal discussions. Early attempts at generating graphics from the tool were slow, technically limiting and sometimes unreliable. This was largely due to the fact that model information was captured into structures that were not designed to enable rapid generation of graphics. We desired to provide the ability for SMEs to easily and rapidly invoke graphical views of the models so that the group tool itself could become a more useful visualization medium.

ICOM connections

Figure 2 - First generation sibling set diagram

In comparison to models developed in traditional JAD sessions supported by a single-user IDEFO tool, the group-enabled modeling environment allowed significantly more people to contribute productively to the modeling session. Models were developed more than twice as fast and the productivity per participant was also markedly higher than achieved in traditionally supported meetings. The models also benefited from having many SMEs contributing their content knowledge to the model.

From our experiences with the first generation tool and from examining other IDEF tools it became apparent that there are several ways to interpret and implement ICOM connections. A strict interpretation of IDEF would allow connections to be created only between activities within the same sibling set, looser interpretations allow connections between any two activities in the model. The early version of the tool restricted activity connections to valid ICOMs from the master ICOM glossary, but did not provide context sensitive searching of ICOMs. Thus, when forming ICOM attachments within a given decomposition, the

453


SME was presented with the entire ICOM glossary, not just a relevant subset. Moreover, no intelligent searching of the list was supported so SMEs had to page down though the entire ICOM glossary to find the specific ICOM they needed. This made attaching ICOMs more tedious than necessary. It was clear that the list should be restricted to ICOMs that are appropriate for each decomposition. Additionally, list searching mechanisms should be provided so that when a SME entered the first character of a particular ICOM the tool should immediately scroll to the first ICOM that had that character as the fist character in its name.

ICOM bundle formation

The IDEFO method includes the concept of balancing boundary arrows (ICOM connections) between the parent activity view and the decomposition of that view in the child diagram. Boundary ICOMs entering and exiting activities are, with rare exception, reflected at their parent levels. A parent activity can have up to 6 child activities (if the model adheres to the FIPs IDEFO standard), and each child can have up to 6 ICOMs attached to any one of its sides. In order to accurately reflect connections of its children, parent activities would be overloaded with up to 36 connections entering/leaving any one of its sides unless ICOMs of the children are aggregated into logical bundles. Logical classes of ICOM connections can be bundled together into a more general ICOMs that enter or exit a decomposition, and therefore the parent. Bundling allows more generalized inputs, outputs, controls, and mechanisms to be shown on the parent diagram which reduces the complexity of the more abstract parent view.

Our early tool allowed SMEs to specify which ICOMs were to be included in each bundle, but did not limit the possibilities to just the ICOMs existent in the current diagram. Thus, narrowing the list to valid candidates was not an easy process. This difficulty was compounded by the graphical viewer’s limitations, such as time delays. Because the entire diagram was often too large to tit on one screen it was impossible to view all of the candidate ICOMs for bundling in any one view. This made bundling during the session tedious and time consuming. Hours of session time were spent bundling because of the limited tool support. Moreover, invalid bundles would sometimes be entered because the tool did not constrain the possibilities to valid candidate ICOMs for each diagram. Thus, the analysts would have to spend time after hours to “debug” the splits and joins and then review the changes with session participants when the session reconvened. It became obvious that a better means was needed to create valid bundles.


Semantic correctness

IDEFO has a defined set of rules which should be followed in order to make models simple to comprehend, internally consistent, and transportable from one environment to another. For example, generally speaking, if a parent level activity produces Budget Report as an output, then Budget Report should be an output of one of its children. Unless this is true, the model violates IDEFO rules. It is also a violation if Budget Report were used as an input, mechanism, or control of any of its children.

We desired to find a solution that would satisfy three requirements: 1) the tool should support appropriate capture of models that adhere to IDEFO standards, but would not force undue restrictions on users to the point that it would restrict parallel work, especially during the idea generation stages of model development when it is desirable to relax rules enforcement; 2) the tool should provide users with regular and detailed feedback regarding portions of the model that are in violation of IDEFO standards so that this information can be used to fix the model; and 3) the tool should provide error checking guidance without adding undue processing overhead to the group tool which tends to be high anyway because of the processing-intensive nature of a group modeling environment.

Group coordination

Keeping a group of 20 to 30 SMEs productively engaged in the modeling process requires skilled facilitation and a tool environment designed to promote parallel group work. The modeling environment must be one which minimizes group process losses (e.g. production blocking, dominance) and maximizes process gains (e.g. synergy, parallel effort, commitment). We uncovered several challenges during testing of the first generation tools. There was no visual manifestation of which activities and ICOMs had been described or for which items improvement ideas had been added. Participants had to look behind each item to determine this. It was impossible to know whether or not the Activity or ICOM was currently being revised by another SME, short of making an unsuccessful attempt to edit it. There was also no way to divide the model across different subgroups so that only those participants designated to work on a part of the model would be able to edit that part. In addition, it was not possible to freeze parts of the model so that they could not be edited.

Our second generation of EA tools was designed to improve these processes and provide a more up-to-date user interface. The following section gives additional

454



information on how these issues were addressed.

Second generation tool’s architecture and features

Based on the experiments using collaborative drawing tools[3][4][5] and our past experiences with using group enterprise analysis techniques, we developed our second generation architecture. As before, this system relies on textual input for the definition of the formal model (Model Builder module), and a graphics generator (Viewer module) to display formal graphics images. New to this system is the ability to access informal graphics generated from a number of sources, and the ability to generate formal graphics reports. Revisions to the underlying database structures reflect the needs for rapid model development, as well as rapid, precise graphics generation. The performance of the Viewer has been enhanced to produce images in a few seconds. Semantic analysis has been added to the Model Builder module of the tool and improved in the Viewer module. The Model Builder module has been redesigned to operate in a GUI environment using a dialog driven interface rather than a forms driven interface. Support for distributed IDEFO kit reviews conducted over the World Wide Web (EA Utility) and the generation of formal graphics from EMS data have also been added.

The second generation system (figure 3) was designed to operate under Microsoft Windows (ver. 3.1) using Borland’s C++ compiler with the Paradox Database Engine and to work in conjunction with Ventana’s GroupSystems for Windows (GSWIN). The software prototype consists of five major modules: Model Builder, EA Viewer2, Report Manager, EA Utility, and GSWIN Viewer.

The Model Builder (figure 4) is a textual database editing tool which allows the creation of the activity node tree, definition of ICOMS, and creation of ICOM connections. The simple lists are presented to SMEs to manage complexity. By clicking on these items, SMEs can attach descriptions, ICOM connections, improvement ideas, and other information relevant to the model. The Viewer module allows the SMEs to view graphical representations of the model (while editing in Model Builder). Report Manager allows the SMEs to create session reports which can be edited and printed by common Microsoft Windows word processors. EA Utility is a facilitator utility program which has the capability of importing and exporting model data, creating HTML files for distributed kit reviews(via the World Wide Web), and managing existing sessions. GSWIN Viewer is a program which allows the SME to create graphical displays (structure charts, cause-effect diagrams, decision trees, etc.), directly from GSWIN data

and has the capability of creating HTML files from GSWIN sessions for distributed kit reviews.

Figure 3 - Second generation tool architecture

Figure 4 - Model builder main screen

The model repository underwent extensive changes in order to provide more functionality and enhance performance. In particular, the number of relational tables used to store ICOM connection information was reduced from 9 to 2. This consolidation of tables eliminated the need for the Viewer module to

455



search multiple tables for matching connection components and eliminated the need for using secondary indexes. The end result of this was faster diagram creation, improved semantic analysis capability, and reduced server overhead. Another major source of performance improvement came with the conversion of Paradox PAL scripts to a C++ object-oriented model builder. This change not only increased performance, but also allowed locking to be done at the record level instead of the form level. This increased the amount of parallel activity among participants and reduced the frustration experienced when participants are denied access to a portion of the model.

The following sections detail enhancements in this generation of the tool that overcome the limitations discussed previously. Specific changes will be discussed that provide better graphical support, easier ICOM connection-and bundle formation, improved error finding and reporting, and more efficient group coordination.

sketching tools [6], and conventional drawing tools such as white-boards. Two outcome measures were used, consisting of the time to complete the task and the quality of the solution--measures commonly used in group support systems research. In addition, videotape was used to provide a more in-depth analysis of how the group worked together. Process variables measured include: the equality of group participation and how the groups worked together (parallel, scribe, or interactive). The results of these experiments showed that there was little difference in solution quality across the means of support, but the time required by groups using the collaborative drawing tools were significantly longer than those using conventional whiteboards.

Graphics support

Participants in IDEFO modeling sessions use both informal and formal graphical techniques. Informal graphics are used in the beginning phases of conceptualization of the model. Formal graphics are used to display interim versions of the model during modeling, as part of the distributed kit review package, and included in the final printed model report.

Informal graphical capability was provided to SMEs in several forms: write-boards at the front of the room, a document camera with the capability to project sketches onto shared screens, and pads of paper. Write- boards are white-boards with the capability to produce hard copy output. The temporary nature of work written on a whiteboard coupled with the difficulty in sharing and preserving paper sketches and write-board output made this aspect of the process less than satisfactory. During tests of the fast generation of tools participants often needed to refer to informal sketches made by themselves and others during the modeling process because of the lengthy amount of time required to generate formal graphics.

The inability of the experimental groups to use the structured drawing program to complete a relatively simple hierarchy with comparable effectiveness (an average of 2.5 times longer to complete the task than conventional whiteboard, .5 times longer than the sketching groups, and twice as many errors), leads us to believe that our original concept of capturing text through forms and using a graphical engine to generate the graphics is the best solution for creating models and displaying formal graphics in a group modeling environment. Furthermore, commercial tools commonly used in business settings (e.g. spread sheets, project management tools) follow the same paradigm of text entry and computer generated graphics. Rather than invest our efforts in creating a graphical editing environment, time was spent on enhancing the speed and quality of our the computer generated graphics and exploring solutions for handling informal graphics.

The ability of the initial tool to generate graphics at their stations prompted some SMEs to ask for the capability to use the graphics screens as an alternate interface for modifying the model. This form of interface is commonly used in single-user commercial tools. To determine the advisability of that request we analyzed a series of experiments previously performed at the University of Arizona.

Aytes [l] conducted a series of experiments aimed at determining how effectively groups could use structured collaborative drawing tools [ 121, collaborative

Based on these findings we rewrote the viewer program for the second generation tool set. The new version took advantage of a restructured database and faster machines to build complex graphics in a matter of seconds (figure 5). Users are saved from having to decide where on the graphical space the activities and ICOMs should be placed because an automatic layout algorithm determines the position of the objects. Also, the viewing capability was integrated with the model building aspect of the tool so that the views could be easily invoked from the same workstation that the SMEs were using to enter model content. Tests performed with this tool suggested that if the generation of computer graphics was fast enough (seconds) and that entering and revising the model was easy, then the use of informal graphics during model creation is greatly reduced, and for some sessions eliminated altogether. Informal graphics, sketches, doodles, and partial drawings, were generated in some cases, but due to their incomplete nature they are of little value out of the context of the discussion during which they were created. Instead, SMEs tend to conceptualize with the formal graphics that can be immediately

456


generated from the model content captured in textual format.

Figure 5 - Second generation viewer in tiled mode

The second generation tool set improved the quality of printed reports as well. In the first generation of tools, text reports were generated from the database forms program and graphics were generated via screen prints of the Viewer program and by exporting the model database to a single-user IDEFO tool. The second generation of tools added a Report Manager module specifically designed to generate reports which integrated the text and graphics into one complete model specification. Reports are generated in rich text (RTF) format which is readable by most PC compatible word processors. Reports may contain activities, ICOMs, bundle reports, connection reports, hierarchy diagrams, node diagrams, and sibling set diagrams. The fmal report is often the only documentation that session participants take away with them, therefore, it must be a comprehensive report which is well organized and complete with graphics.

ICOM connections

Features were added to the tool to ease the forming of ICOM connections. Now when creating connections, SMEs have the ability to specify which ICOMs should be shown. Depending on the SME’s selection, the tool will show all existing ICOMs or just those used by parents, siblings, or children of a given activity (figure 6). Moreover, when a participant enters the first character of the ICOM name, the tool zooms to the ICOMs in the list that start with that character. This saves time searching a lengthy list and helps to reduce the number of redundant ICOMs.

As another model development aid, the tool also has a feature to support appropriate propagation of


ICOMs up and down the levels of abstraction. Since a parent IDEFO diagram is a more general representation of its child decomposition, it is often helpful to see ICOM attachments at the child diagram level before creating the more generalized parent representation [ 10][9]. This is probably due to the fact that it is difficult to think of aggregates of connections at the more general level of abstraction without seeing the details that are generalized by those more general abstractions. In order to facilitate the definition of parent ICOM connections, the program allows connections to be created at any level of the tree. Additionally, the tool has an automated option for propagating connections up the node tree. The facilitator may elect to tell SMEs to create connections just at the leaf level. The automatic propagation function can then be run to identify candidates that may be propagated at higher levels of the tree. Candidate ICOMs can be bundled as appropriate. This helps eliminate upward propagation problems. The model analysis function and viewer can be invoked at any time to locate bundling and propagation errors.

Figure 6 - Model builder connection dialog

ICOM bundle formation

A bundling dialog was added to the tool that restricts the view of candidate ICOMs to those that can be validly bundled for any one decomposition. In this way, the user selects which type of ICOM for that diagram to be bundled (input, output, control, or mechanism). For example, if the user specifies that (s)he wishes to bundle outputs, all outputs from all activities for the decomposition are shown on a list. The SME can click on the ICOMs that are to be bundled and then may select or create a more general ICOM to represent the aggregate of the more detailed ICOMs. A graphical display of the result is then shown in the bundling dialog (figure 7).

457


These bundles are also reflected iu the graphical view of the model.

Figure 7 - Model builder bundle dialog

Bundling can be performed on an individual activity or a sibling set basis. As with the creation of connections, potential ICOMs for selection as the aggregate of each bundle can be selected from the entire ICOM set, or just those existing at the parent/child level of the given activity. This facility saves hours of work in the session by making bundling very simple. Users and analyst see valid candidates for bundling on one list and bundles can be formed much more quickly and simply than in the older version of the tool.

Semantic correctness

The final result of a modeling session should be a fully compliant IDEF model. However, during intermediate development stages it may be helpful to temporarily deviate from the strict rules in order to allow participants to enter data freely. For example, when detailing the sibling set of a particular node, 10 activities may be defined. This violates the maximum of 6 siblings allowed by IDEF. However, it may be better to allow all 10 to be entered, and then have the participants determine how these 10 activities should be restructured to be within the IDEFO rules. Allowing a certain amount of freedom allows different facilitation styles to be used (top down, bottom up, inside out, etc.), while providing a mechanism to identify and correct model errors to insure compliance with standards.

Our approach purposely contains some elements of both restrictiveness and flexibility. The goal is to minimize the distraction of restrictive enforcement of the rules and at the same time provide for enough guidance that problems can be identified and resolved quickly. This keeps the focus on the content so that participant’s efforts are focused on the description of the domain. We


attempted to create modeling tools that are simple and friendly to use, yet powerful enough to provide effective support for model development. The number of modeling rules that are enforced in a restrictive manner is relatively small. Only those rules that were clear and straightforward for SMEs were left as restrictive. For example, activity names must be unique. The vast majority of the rule tests were shifted into an option that can be invoked upon demand by the SME. This keeps SMEs from being unnecessarily intimidated, and yet provides guidance regarding fixing the model. Relaxing modeling restrictions allows for more diverse facilitation styles to be supported and for increased parallel activity by the participants. A successful strategy is to allow SMEs to a create a portion of the model, then check for, and resolve any errors that may occur. The semantic checking engine can be invoked from any station and a list of warnings alerts the SME of violations. In addition, the periodic nature of this checking, reduces overhead that would be unduly high were the tool to enforce semantic rigor one each and every entry at the time of entry.

Figure 8 depicts the Model Builder analysis function. The Model Builder analysis function generates a list of errors, provides a help reference for each error, and has a fix button which takes the SME to a dialog box where the error can be corrected. Model Builder checks for 28 different modeling violations. These checks can be individually enabled and disabled. An analysis can be performed on the entire model, a given sibling set, or any model subtree.

Figure 8 - Model builder analysis dialog

The other form of error feedback is provided

458


through visual cues given by the viewer program. It performs semantic checking of connections between activities. Violations of IDEF rules and model inconsistencies are flagged with red dots (figure 9). Explanations of errors are available via a pop-up dialog.

Figure 9 - Viewer semantic warnings

Group coordination

In order to minimize group process loss, e.g. production blocking and dominance, and maximize process gain, e.g. parallel work and synergy, the second generation tools were given several new capabilities. These capabilities include better mechanisms for the coordination of work, timely updates of screens, and the ability for the facilitator to create subgroups of SMEs. Coordination mechanisms include status indicators on the main displays which tell the SMEs whether an activity or ICOM is being edited by another SME, has an improvement idea, has a description, or has been marked for deletion.

Model Builder provides the facilitator with the ability to create subgroups, assign activity subtrees and edit rights to subgroups, and assign SMEs to subgroups. A subgroup may contain access rights to many activities and may have many members. An SME can be a member of many subgroups. This allows the facilitator to create a subgroup configuration with the maximum amount of flexibility. One subgroup can be given full edit privileges to one subtree, and read access to the rest, etc. Users which are members of several subgroups can act as floaters, i.e. persons who track activity in several portions of the model in order to help maintain consistency.

In addition to subgroup privileges, facilitators can place read/edit/delete locks on individual activities and ICOMs. Therefore, if there is a dispute over a


particular activity, its current state can be locked until the disagreement is resolved. Dysfunctional group members can be assigned to a special group which provides only read access to the model, which would require all their input to the model to be done (and filtered) by a responsible participant.

Conclusions and future research

Clearly, group-enabled modeling tools require features that can elegantly support collaborative model development. This research discusses the discovery of the need for some of these features within an IDEFO modeling environment. This paper has detailed how we used advances in object-oriented technology and our increased knowledge of group dynamics and the modeling process to improve five critical areas of group activity modeling. These were: graphics generation, ICOM creation, bundle formation, semantic analysis, and group coordination. Graphics were improved by allowing SMEs to quickly generate diagrams at their stations and by integrating diagrams with text and tables in printed reports. ICOM creation and bundle formation operations were enhanced by the addition of intelligent pick-lists and graphical bundle displays. Identification of IDEFO semantic violations are visually displayed using the red dots in the Viewer and by a semantic analysis engine in the Model Builder which is capable of detecting 28 different rule violations. Finally, group coordination has been improved by allowing facilitators to create subgroups of SMEs, freeze portions of the node tree, and improved visual cues. The second generation Enterprise Analysis tool set is currently being evaluated in a number of DOD and industry case studies. To date, the tool set has been successfully used by many groups for development and analysis of models ranging from environmental planning to business travel planning.

We are continuing to enhance and improve the IDEFO EA tool kit. Our goals are to improve the entire business process reengineering process and to make the tool useful for other aspects of enterprise management, for example, activity based costing, and resource planning. At this time we have implemented, but not field tested several useful additions. These include:

. Distributed Kit Review via the World Wide Web - performed by the automatic generation of HTML scripts with graphics and annotation capability. It is hoped that this feature will cut weeks off the model review cycle when models need to be reviewed by individuals not directly involved during model development. This also allows reviewers to communicate with one another about model improvement suggestions and improvement ideas.

459


Proceedings of the 29th Annual Hawaii International Conference on System Sciences - 19%

l Automatic ICOM Connection Propagation - algorithms and procedures which automatically generate missing ICOM links as appropriate up the node tree.

l Configurable fields - Gives modelers the ability to add extra data fields to ICOM and activity records for the purpose of cost analysis, resource planning, and project management. In addition to our work which extends IDEFO,

researchers at the University of Arizona are performing work on group enabled IDEFlx tools, model repositories, IDEF4 object oriented process design, and distributed modeling sessions.

References

1. Aytes, K.J. An empirical investigation of collaborative drawing tools. (1993), Unpublished Doctoral Dissertation, University of Arizona.

2. Davenport, T.H. and Stoddard, D.B. Reengineering: business change of mythical proportions? Management Information Systems Quarterly, (June 1994), 121-127.

3. Dean, D.L.; Lee, J.D.; Orwig, R.E.; and Vogel, D.R. Technological support for group process modeling. Journal of Management Information Systems, 11, 3, (Winter 1994-95), 43-64.

4. Dean, D.L.; Orwig, R.; Lee, J.D.; and Vogel, D.R. Modeling with a group modeling tool: group support, model quality, and validation. Proceedings of the 27th Annual Hawaii International Conference on System Sciences. 1994,214-224.

5. Dennis, A.R.; Hayes, G.S.; and Daniels, R.M. Re-engineering business process modeling. Proceedings of the 27th Annual Hawaii International Conference on System Sciences. 1994,244-254.

6. Greenberg, S. and Bohnet, R. Group sketch: a multi-user sketchpad for geographically-distributed small groups. Graphics Interface Conference, 199 1, Calgary, Canada.

7. Hammer, M. Re-engineering work: don’t automate, obliterate. Harvard Business Review, (July-August 1990), 104-l 12.

8. Hammer, M. and Champy, J. Reengineering the Corporation: A Manifesto for Business Revolution. New York, NY: Harper Business, 1993.

9. IDEF Users Group Standards and Specification Committee. IDEFO FIPS Comment Document. (1993), IDEF Users Group Standards and Specifications Committee, IDEFO Working Group.

10. Marca, D.A. and McGowan, C.L. SADT: Structured Analysis and Design Techniques. New York, NY: McGraw Hill, Inc., 1988.

11. Mayer, R.J.; Painter, M.K.; and dew&e, P.S. IDEF Family of Metho& for Concurrent Engineering and ’ Business Re-engineering applications. (1994), Knowledge Based Systems, Inc.

12. Pendergast, M.O. GroupGraphics: prototype to product., ed. R. Rada, S. Greenberg, and S. Hayne: McGraw-Hill, Forthcoming.

13. Ross, D.T. Structured Analysis (SA). A language for communicating ideas. IEEE Transactions on Software Engineering, SE-3, No. 1, (January 1977), 16-34.

14. UM. Integrated computer-aided manufacturing (ICAM function modeling manual (IDEFO). (198 l), Materials Laboratory, Air Force Wright Aeronautical Laboratories, Air Force Systems Command, Wright-Patterson AFB, OH.

460


current advances in group-supported business process ... · pdf filecurrent advances in...

Documents