SCOPE: An Environment for Continuous Improvement Teams in ...

In: Proceedings of the ED-MEDIA'99 – World Conference on Educational Multimedia, Hypermedia & Telecommunications, pp. 957-962, Seattle, Washington, June 19-24, 1999.

SCOPE: An Environment for Continuous Improvement Teams in Virtual Corporations Yongwu Miao, Hans-Rüdiger Pfister, Martin Wessner & Jörg M. Haake GMD - German National Research Center for Information Technology Integrated Publication and Information Systems Institute (IPSI) Dolivostr. 15, D-64293 Darmstadt, Germany E-Mail: {miao, pfister, wessner, haake}@darmstadt.gmd.de

Abstract: A continuous improvement team is a group of people who work together on the same project and are committed to continuous improvement of their work processes. In order to support continuous improvement teams in a virtual corporation, a comprehensive system is needed to support integrated collaborative work and collaborative learning processes. In this paper, the SCOPE system is presented, which provides support for the definition, modification and execution of session-based collaborative processes for continuous improvement teams.

1 Introduction A virtual corporation is a temporary network of independent operating units such as creative designers, manufacturers, suppliers, customers, and other experts in marketing and finance linked by interactive multimedia networks to share skills, production facilities, resources, to decrease costs and to increase access to each other's markets. In virtual corporations, the definition of a task is continually changing, and its product is a so-called virtual product that adapts in real time to the customer's changing needs [Davidow & Malone 93]. Excelling in a dynamic business environment requires more common understanding and agreement among team members than individuals' expertise and experience provides. In the life cycle of a virtual corporation, cross-functional teams need to continually expand their capacity to improve their work, processes, relationships and environment. Such a team, called a continuous improvement team (CIT), is a group of people who work together on the same project or who come together to solve a common problem, and are committed to continuously improve the processes on which they depend to get their work done [Hutchings et al. 93]. In order to support CITs in virtual corporations, a comprehensive environment is needed to overcome the barriers of physical separation and to support integrated collaborative work and collaborative learning processes. Existing learning support systems are designed according to one of three metaphors: session, process and place. Systems that rely on a sole metaphor provide insufficient support for continuous improvement processes [Hutchings et al. 93]. In addition, most collaborative learning support systems are separate from collaborative work support environments. In this paper, we present our approach to support an integrated collaborative learning and collaborative work process. The prototype system, session-based collaborative process-centered environment (SCOPE) integrates process support technologies into a collaborative support environment. A session is defined as follows: in a period of time activities are performed by multiple actors with different roles in a shared information space to achieve an elementary goal. A sessionbased collaborative process (SCP) denotes a process that consists of a set of coordinated sessions [Miao & Haake 98a]. SCOPE provides support for the specification, modification, and execution of session-based, integrated collaborative work and collaborative learning. The remainder of this paper is organized as follows: In the next section, characteristics of continuous improvement processes and major requirements are identified. Section 3 presents related work. Section 4 describes how SCOPE supports continuous improvement processes. Finally, we present our conclusions and future work.

2 Requirements for the Support of Continuous Improvement Teams In order to identify the characteristics of continuous improvement processes and the major requirements of the support system, a scenario in a virtual corporation is developed, which is based on a real scenario presented in [Hutchings et al. 93]. 2.1 A Scenario Seven members of a team in a virtual software corporation are responsible for designing a software product. The team consists of software engineers and requirement analysts who are geographically distributed. The team wishes to learn how to perform continuous improvement. The team and software process consultants jointly determine what is needed to improve the team's capabilities. Then, training consultants design a training course for the team. They create and customize necessary materials. Such a course takes into account the team's total work situation, team’s present job tasks and their social environment. The training course consists of a series of sessions. The sessions take place in working hours and are conducted in the same environment as collaborative work. In the first lecture session, the team learns sound decision-making strategies and principles. After the lecture, the team practices separately in two groups (function design group and interface design group) and sets up the strategies for how they would like to make group decisions. Then, they switch to their collaborative work processes and follow the strategies to make decision for their design. During work processes, the data collected and practice results achieved will be transferred into collaborative learning processes as parts of materials of the following sessions. In the succeeding learning session, the teacher guides the team to analyze and evaluate the currently used decision-making strategies. After that, the team will learn and try to improve their decision-making strategies and use the improved strategies to get their work done. That is, collaborative learning and collaborative work in virtual corporations form a process in which the team as a whole continuously reflects upon events, gains knowledge about job tasks and work processes, improves product quality and work processes, and discovers their learning needs in the workplace continuously. 2.2 Characteristics of Continuous Improvement Processes Based on an analysis of the scenario described in the previous sub-section and a reference of design principles presented in [Hutchings et al. 93], the characteristics of continuous improvement processes can be identified. • Modularity for flexibility: Information and materials used and produced in learning activities or working activities are documented as modules. They are constructed as typed and self-contained units of information -- artifacts. Modularized, structured artifact models are beneficial for the team's common understanding and communication. • Team-based collaborative learning and collaborative work activities: Interventions are delivered in team sessions, and emphasize collaboration and shared responsibility. Sessions are designed for team members to gain new skills and knowledge together. In addition, team members collaboratively perform job tasks also in sessions. Team members may adapt or improve collaboration strategies to conduct sessions according to their learning. • Phased delivery: Interventions are phased in their delivery over time. Intervals between learning sessions provide opportunities for the team to apply learning in work. The data collected and test results achieved in working sessions will be transferred to the succeeding learning session. Team members have to schedule an integrated collaborative learning and collaborative work plan to help communication, understanding, and coordination among team members. There are dependencies among sessions, such as temporal sequencing, as well as among participants and artifacts. • "Just-in-time" effort: Learning and its application occur almost simultaneously. In a virtual corporation, the external environment and customer demands are dynamic and changeable. In turn, team's business goals and needs related to a team's mission should be adapted to the changing environment. 2.3 Major Requirements In order to design an integrated computer-supported environment, according to the analysis of

characteristics, the major requirements are identified as follows: (R1) Support for dealing with artifacts: The artifacts are modularized and structured, and should be adjusted and tailored dynamically according to the team's progress. (R2) Support for session activities: The system should support team members with different roles to perform collaborative activities in a shared information space. In addition, the system should provide facilities for team members to define and modify collaboration protocols, a computational description of a collaboration policy or co-decision strategy. (R3) Support for definition and execution of SCPs: A SCP model is a computational description of a project plan or a curriculum. The system should enable team members to define process models. It is desirable that process models can be used to coordinate group work and learning activities automatically. (R4) Support for dynamical and collaborative change of process models by teams: The system should support team members to modify SCPs on the fly. Instead of a single-user process modeling tool, the modeling tool should be able to be used jointly by teams.

3 Related Work In this section, we investigate existing systems in two aspects, system development and integrated collaborative work and collaborative learning support environments. 3.1 Development Approaches of Learning Systems Most existing learning systems or environments are based on one of three metaphors: session, process and place. Session-based systems support team members to collaborate within single sessions or meetings. They provide an environment for sharing information and performing collaborative activities at the same time. These systems, such as Microsoft NetMeeting [http://www.microsoft.com/netmeeting], provide support for dealing with artifacts (R1) and for session activities (R2), but have no support for the remaining requirements. Process-based systems provide support for structuring stages according to the content structure in a overall learning process. Learners can progress at different speeds in the learning process. These systems focus on individual learning. Obviously, these systems have no sufficient facilities to support session activities (R2). Place-based systems provide virtual places to hold meetings or to perform activities asynchronously. All of the artifacts produced in meetings or individually are left in the places to be reused in the succeeding activities. However, the sequencing of activities performed in places and the transferring of artifacts has to be done manually. A lot of place-based learning systems have been developed recently, such as Virtual Places [http://www.virtualplaces.com], CSILE [Scardamalia et al. 94], VITAL [Pfister et al. 98]. These systems also provide support for dealing with artifacts (R1) and for session activities (R2). However, they can not meet the requirements related to support for SCPs (R3 and R4). Mixed approach: Some information sharing systems (session-based systems and place-based systems) add means for embedding the group's overall work process into a general collaborative learning environment. For example, CLARE [Wan & Johnson 94] is developed based on a model of three-phase collaborative learning processes. The process can be regarded as a SCP to some extent. However, it offers no support for dynamical and collaborative change of SCPs (R4), because it supports a fixed, domain-specific process model. 3.2 Integrated Collaborative Work and Collaborative Learning Support Environment Most collaborative learning support systems can not support learning in work settings. They normally support open-enrollment styles of training which focus on improving individuals. Learners may successfully gain knowledge in courses and then they will apply their learning at different places. Such courses rarely take into account learners' present job tasks and their social environment. Some systems can be used to support both collaborative learning and collaborative work separately, because they only provide general communication support. However, to the best of the authors' knowledge, no system can support learners to define and modify a computational description of their work processes as learning practices, and to coordinate their collaborative work by using the computational description of their work processes. No system can support automatically transferring the data collected and the practice results achieved in work processes into learning processes as

part of learning materials.

4 The SCOPE System In this section we present our approach to support CITs. This approach can be characterized by using hypermedia to represent artifacts in a flexible way, providing shared hypermedia workspaces for sessions, using hypertext structures to specify and modify organizational structure, collaboration protocols, and SCPs, • facilitating the execution of SCPs and collaboration protocols. This approach has been tested in the SCOPE system [Miao & Haake 98a]. Next, we discuss how to support the specification of SCPs. Then support for continuous improvement processes at run time is presented. • • •

4.1 Specification of SCPs In this sub-section, we present our approach to specify SCPs. We discuss how to specify sessions first and then present how to specify a SCP. 4.1.1 Specification of a Session In SCOPE, a session is created for a CIT to learn or perform job tasks collaboratively. In a session, the common information space is potentially accessible by all team members involved in this session. Team members can perform operations synchronously or asynchronously to construct shared artifacts together, and to perform actions to change the state of collaboration. It is important to notice that a CIT consists of members who may have different privileges and responsibilities to deal with artifacts and to coordinate their efforts. To define a new session, team members are required to set values of attributes for the session. Without being exhaustive these attributes include: session name, session type, session creator, session description, collaborative mode, artifact models, collaboration protocol, mapping from organizational to functional roles, scheduled start and end times, etc. Some attributes used in specifying a session are defined by using specific tools: organizational structure definition tool, artifact definition tool, and collaboration protocol definition tool. Definition of members and teams: Members and teams are defined by using the organizational structure definition tool. With this tool, a member, an organizational-role or an organizational-unit is represented as a node with a type, a unique name and a set of attributes to describe properties. The typed links are represented as direct arrows between suitable nodes. A description of an organizational structure is represented as a Directed Acyclic Graph. Definition of the artifact model: An artifact model is defined in terms of task-specific typed hypertext objects (nodes and links) together with operations on them to support a certain activity [Streitz et al. 89][Wang & Haake 97]. Artifacts are organized into these node and link types according to their structure, function, and behavior properties. An artifact may be hierarchically structured, and the structure of aggregated artifacts can be defined in an artifact definition tool, which is a part of the COWFISH system [Wang & Haake 97]. Definition of collaboration protocols: A collaboration protocol is described like a state-transition diagram where a node may contain a sub diagram describing the state represented by that node in more detail. A state node in a diagram represents a state within the collaboration protocol. A link in a diagram represents an event. The occurrence of an event causes a transition between the two states connected by the link. Each state of the collaboration is associated with a set of behavior rules. A behavior rule specifies which roles are permitted to perform which operation on what type of artifacts. A link is associated with a behavior rule or a logical expression. The detailed description of collaboration protocols is presented in [Miao & Haake 98b]. 4.1.2 Specification of SCPs Every SCP is represented by its description, which is called a process model. This description specifies all sessions embedded in the process and the relationships among these sessions. SCOPE provides a visual process model language for process definition. A process model is described as a hypertext document consisting of nodes that are connected via links. A process can be decomposed into sub-processes. The

components and the structure of a (sub)process are described inside the (sub)process node. Session nodes, the elements of processes, are specified in the way described above. The process models are specified in SCOPE by using the process definition tool (see Fig. 1). The tool shows a window title bar listing the name of the overall process model and the tool type. Below that is a list of icons showing the current users of the tool, followed by a button bar with generic functions for editing, navigating hypertext documents, and specific functions for editing process models, followed by a palette of components of the visual process model language (left side) and the content pane (right side) displaying a process model. In Fig. 1, an example of a process model is presented, which describes the collaborative learning process explained in the scenario (see Chapter 2.1). This part of process model consists of a session for collaboratively customizing materials, a lecture, two practice sessions, and a workshop. They are connected by temporal links, such as “finish-trigger” and “AND-split”, and by artifact links with named artifact buffers. It is important to note that the artifact input/output buffers are used to exchange artifacts across (sub)processes. For example, in practice sessions, decision-making strategies are defined as collaboration protocols that will be transferred to the collaborative work process. The defined collaboration protocols will be initiated in groups’ collaborative work sessions, and guide and control group decision-making processes for design. The feedback from the collaborative work process will be imported into the workshop via an artifact-input node. After a process model is defined, it can be stored in a process model base and can be instantiated and reused. Next, we will discuss the run-time features of SCOPE.

Figure 1: An example of a process model 4.2 Support for Continuous Improvement Processes at Run Time Process execution is concerned with the enactment of a process following the previously defined process model. Now, we discuss process execution from the users' perspective. Team members can select a pre-defined process model from the process model base as their initial process model. If no suitable process model exists, they can define a new one. When they start to execute the process model, an instance of this process model is created. This process instance will progress according to its process model. Support for execution of session activities: Each team member has a personal information panel. In this panel, information is listed about processes and sessions in which he/she should be involved. He/she can join a session by selecting it from the session list. When he/she joins a session, the top-level of the shared information space of the session is displayed in the session browser and he/she can browse through the

artifacts following the recorded dependencies. In this browser there is a palette that lists the artifact types, which are allowed to be created in the current state according to the rules defined in the collaboration protocol of this session. The shared artifacts can be viewed and edited simultaneously by team members working in the session depending on their access rights. When a user performs an operation on an artifact, the system will check whether this member has the access right to execute the operation according to rules defined at this state of collaboration. If the check is successful, the change will be propagated to all sites. To maintain consistency for concurrent changes at different sites, a fully replicated concurrency control mechanism is provided by COAST [Schuckmann et al. 96]. Transitions from one state of collaboration to another may be carried out by team members who have the right to perform actions. Allowed actions are also listed in a palette in the session browser. Each session has an autonomous agent that monitors the status of collaboration periodically by evaluating the transition conditions. If a condition is met, the system changes the state according to the collaboration protocol. Support for execution of SCPs: Changes of the state of collaboration in one session may result in changes of the state of related sessions according to the process model. In the case of two sessions connected by a “finish-trigger” link, once the source session is finished, the state of the destination session will change. In SCPs, artifacts will be automatically transferred between sessions according to the process model. Support for dynamical change of SCPs: Even when a process instance has already been created, parts of the process model can be modified. That is, the values of attributes of the related sessions can be modified and the model of a sub-process can be altered.

5 Conclusions and Future Work In this paper, we described the major requirements for supporting CITs in virtual corporations. Based on the concept of session-based collaborative processes, we developed a modeling methodology and an environment, SCOPE. The system can support definition and execution of session-based collaborative processes. This is realized by maintaining shared hypermedia workspaces with the aid of data level control mechanisms, such as access control and fully replicated concurrency control, and user level control mechanisms, such as collaboration protocols and SCP models. In addition, the SCOPE system provides a high level of flexibility for team members to adapt artifact models and to modify process models at run time. By using the facilities provided in the SCOPE, members of continuous improvement teams can define and execute integrated collaborative work and collaborative learning processes. They can improve their work processes through applying their learning and identify learning issues at work to fit the changes inside and outside of virtual corporations. SCOPE is a prototype system of our ongoing research project and is currently being tested in our group. Most of our work to date has been focused on demonstrating the feasibility of implementing and using the system. We will develop more collaborative tools required by software development and total quality management. We will further test and evaluate the usefulness of the system in more real-world settings.

References [Davidow & Malone 93] Davidow, W.H. & Malone, M.S. (1993). The Virtual Corporation. HarperBusiness, 1993. [Hutchings et al. 93] Hutchings, T. et al. (1993). Process Improvement That Lasts: An Integrated Training and Consulting Method. Communication of the ACM, 36 (10), 105-113. [Miao & Haake 98a] Miao, Y. & Haake J.M. (1998). Supporting Concurrent Design by Integrating Information Sharing and Activity Synchronization. ISPE CE98, Tokyo, Japan, 165-174. [Miao & Haake 98b] Miao, Y. & Haake, J.M. (1998). Flexible support for group interactions in collaborative design. CSCWID98, Tokyo, Japan, July 15-18, 1998. [Pfister et al. 98] Pfister, H. R., Schuckmann, C., Beck-Wilson, J., & Wessner, M. (1998). The metaphor of virtual rooms in the cooperative learning environment CLear. N. Streitz, S. Konomi & H.J. Burkhardt (Eds.), Cooperative Buildings. Integrating Information, Organization and Architecture. 107-113. Berlin: Springer. [Scardamalia et al. 94] Scardamalia, et al. (1994). The CSILE project: Trying to bring the classroom into World 3. Mcgilly Kate (Ed). Classroom Lessons: Integrating Cognitive Theory and Classroom Practice. Cambridge: MIT Press.

[Schuckmann et al. 96] Schuckmann, C., Kircher, L., Schümmer, J. & Haake, J.M. (1996). Designing Object-oriented Synchronous Groupware With COAST. ACM CSCW’96. 30-38. [Streitz et al. 89] Streitz, N., Hannemann, J. & Thuering, M. (1989). From Ideas and Arguments to Hyperdocuments: Traveling through Activity Spaces. ACM Hypertext’89, 343-364. [Wan & Johnson 94] Wan, D. & Johnson, P.M. (1994). Computer Supported Collaborative Learning Using CLARE: the Approach and Experimental Findings. ACM CSCW’94. 187-198. [Wang & Haake 97] Wang, W. & Haake, J.M. (1997). Supporting user-defined activity spaces. ACM Hypertext’97, 112123.

Acknowledgements We want to thank Christian Schuckmann and Weigang Wang for their help with implementing the SCOPE system and Daniel Tietze for helpful comments.