Virtual situation rooms: connecting people across enterprises for supply-chain agility

Virtual situation rooms: connecting people across enterprises for supply-chain agility

COMPUTER-AIDED DESIGN Computer-Aided Design 32 (2000) 109–117 www.elsevier.com/locate/cad Virtual situation rooms: connecting people across enterpris...

1009KB Sizes 3 Downloads 33 Views

COMPUTER-AIDED DESIGN Computer-Aided Design 32 (2000) 109–117 www.elsevier.com/locate/cad

Virtual situation rooms: connecting people across enterprises for supply-chain agility W.J. Tolone* Department of Computer Science, University of North Carolina at Charlotte, 9201 University City Boulevard, Charlotte, NC 28223-0001, USA Accepted 2 September 1999

Abstract Agility and time-based manufacturing are critical success factors for today’s manufacturing enterprise. To be competitive, enterprises must integrate their supply chains more effectively and forge close memberships with customers and suppliers more quickly. Consequently, technologies must be developed that enable enterprises to respond to consumer demand more quickly, integrate with suppliers more effectively, adapt to market variations more efficiently and evolve product designs with manufacturing practices more seamlessly. The mission of the Extended-Enterprise Coalition for Integrated Collaborative Manufacturing Systems coalition is to research, develop, and demonstrate technologies to enable the integration of manufacturing applications in a multi-company supply chain planning and execution environment. We believe real-time and asynchronous collaboration technology will play a critical role in allowing manufacturers to increase their supply chain agility. We are realizing our efforts through our Virtual Situation Room (VSR) technology. The primary goal of the VSR technology is to enhance current ad-hoc, limited methods and mechanisms for spontaneous, real-time communication using feature-rich, industry standards-based building blocks and network protocols. VSR technology is being designed to find and engage quickly all relevant members of a problem solving team supported by highly interactive, conversational access to information and control and enabled by business processes, security policies and technologies, intelligence, and integration tools. q 2000 Elsevier Science Ltd. All rights reserved. Keywords: Collaborative systems; Supply chain integration; Real-time conferencing

1. Introduction Agility and time-based manufacturing are critical success factors for today’s manufacturing enterprise. To be competitive, enterprises must integrate their supply chains more effectively and forge close memberships with customers and suppliers more quickly. Currently, integration-enabled manufacturing software as well as software that supports supply chain management are in high demand. According to the AMR estimate, supply chain management software is likely to cross US$920 million in 1998—an expected increase of nearly 300% over 1996 [1]. Why is the manufacturing supply chain attracting so much attention from the software industry? Based on data from the US Department of Commerce, Benchmarking Partners projected retail sales for 1997 at approximately US$2.6 trillion. To support that level of sales, it is estimated that retailers, wholesalers, wholesale suppliers and manufacturers collectively held approximately US$1 trillion in

* Tel.: 11-704-547-4880, fax: 11-704-547-3516. E-mail address: [email protected] (W.J. Tolone).

inventory [2]. Thus, technologies that enable even modest reductions in inventory may collectively save enterprises billions of dollars (e.g., a 2% reduction would free up nearly US$20 billion in capital, yearly). We believe a key to inventory reduction is the development of technologies that enable enterprises to respond to consumer demand more quickly, integrate with suppliers more effectively, adapt to market variations more efficiently and evolve product designs with manufacturing practices more seamlessly. Consequently, in 1998, the ExtendedEnterprise Coalition for Integrated Collaborative Manufacturing Systems (EECOMS) [3] was established with the help of the US Department of Commerce NIST/ATP Technology for Integrated Manufacturing Application (TIMA) initiative. The mission of this coalition is to research, develop, and demonstrate technologies to enable the integration of manufacturing applications in a multi-company supply chain planning and execution environment. The coalition is targeting three technology areas that it believes are critical to the success of this mission. These areas include: • technologies for manufacturing business users to capture

0010-4485/00/$ - see front matter q 2000 Elsevier Science Ltd. All rights reserved. PII: S0010-448 5(99)00094-9

110

W.J. Tolone / Computer-Aided Design 32 (2000) 109–117

and modify their supply chain designs by changing and validating business rules; • technologies that support a practical security framework for multi-enterprise transactions and interactions; • technologies that enable users to construct Virtual Situation Rooms (VSR) where geographically distributed people can collaborate with each other to resolve supply chain problems. In this paper, we present the coalition’s early research and development efforts regarding the latter of these technology areas, i.e. technologies for connecting people across manufacturing supply chains. Although we believe such technologies are critical to inventory reduction, we also recognize that inventory reduction is not the only key to more cost-effective supply chain management and integration. However, it is our belief that advances in collaboration technologies that enable inventory reduction will also support other keys to more cost-effective supply chains. (In fact, we view this as an essential requirement to our research and development efforts.) The structure of this paper is divided into three parts. First, we present an overview of common manufacturing practices and identify two existing supply chain models as well as one new model designed to support these practices. As part of this overview we underline the importance of asynchronous and real-time collaboration support to support these practices and models. Second, we outline our collaboration technology solution, VSR, highlighting its vision, user view, and architectural design. Included in this outline is a discussion of some of the underlying technologies that we believe will contribute to the design and implementation of our solution. Third, we demonstrate the VSR technology via a scenario that demonstrates the use of VSR to better integrate engineering changes with manufacturing practices. This paper concludes with a brief discussion of related work, current project status, and some final thoughts. 2. Manufacturing supply chains In the following subsections we provide an overview of manufacturing practices and supply chain models. A more extensive discussion can be found in Ref. [2]. As part of this overview we underline the importance of asynchronous and real-time collaboration support to support these practices and models. 2.1. Manufacturing practices There is a variety of manufacturing practices in use today. In the following, we overview the most common practices and discuss some of the implications of those practices on manufacturing supply chains. In particular, we focus on those implications that impact the requirements and designs for supply chain collaboration support.

2.1.1. Engineer to order Manufacturers who engineer to order typically provide low volume, highly specialized products. With engineer to order, production does not begin until the consumer defines product specifications; i.e., demand occurs prior to the start of production. For such manufacturers, it is very difficult to identify suppliers in anticipation of demand. Consequently, the manufacturers must be able to identify and negotiate short-term contracts with suppliers in a timely fashion. In addition, due to the potential uniqueness of the demand, the manufacturer and consumer often must work in concert to ensure product specifications are both accurate and appropriately met. 2.1.2. Make to order Manufacturers who make to order typically produce specialized products from a predefined list of products. Therefore, parts of a manufacturer’s supply chain may be defined prior to demand while the remainder is defined after demand. The difference between make to order and engineer to order is that with make to order, the products are already engineered, but, to satisfy a demand, a make to order manufacturer might need to order further materials, retool machines, etc. As with engineer to order, demand is satisfied through production. With engineer to order and make to order, product inventory often is extremely low. Thus, further reducing inventory may not offer significant savings to manufacturers. Nevertheless, real-time and asynchronous collaboration support can improve supply chain efficiency for these manufacturers and thus offer potential savings. The savings lie in the ability for such technology to facilitate supply chain negotiations to meet consumer demands as well as to support consumer consultations to verify product correctness. 2.1.3. Assemble to order With assemble to order (sometimes referred to as configure to order) consumers demand a customized product. Such a product may be quickly produced because these manufacturers will produce product components in anticipation of demand and only assemble these components into a finished product in response to actual demand. Assemble to order is different than make to order because product components are produced prior to demand. Here, the ability to establish supply chain agreements quickly is necessary only when special product components are required. 2.1.4. Make to stock When product demand fluctuates and supply chains are unable to adapt quickly enough, manufacturers will make to stock in order to have inventory on hand to meet demand. These manufacturers use post-demand feedback as well as demand forecasts to determined their desired inventory levels to compensate for a lack of supply chain agility.

W.J. Tolone / Computer-Aided Design 32 (2000) 109–117

111

Fig. 1. The SCOR model.

Thus, with make to stock, production occurs in anticipation of demand. With both assemble to order and make to stock, product inventory often is high. (With assemble to order, inventory is held as product components.) We believe real-time and asynchronous collaboration technology is critical for increasing manufacturers’ supply chain agility. If supply chains are more responsive, then manufacturers can be more responsive. Thus, through a combination of technologies (including collaboration technology) the potential exists for reducing inventory levels. This same rationale applies also to distributors and retailers.

2.2. Supply chain models No single supply chain model is appropriate for all of the discussed manufacturing practices. However, a combination of supply chain models can lead to greater supply chain agility and subsequent inventory reductions. In the following, we highlight two prominent supply chain models as well as one new model developed by the EECOMS project. Each model brings a different perspective to the supply chain problem.

2.2.1. Supply chain operations reference model (SCOR) The SCOR [4], proposed by the AMR supply chain council, offers enterprises a simple framework by which internal and external supply chains may be analyzed and, thus, better understood. The SCOR model is comprised of four activities, plan, source, make and deliver, where planning activities extend across the sequential activities of source, make and deliver. These four activities occur identically up and down the supply chain. For example, the source activities of one enterprise might overlap the delivery activities of another (see Fig. 1). As this model demonstrates, changes within enterprises can produce ripple effects up and down the supply chain. To combat the ripple effects, the AMR suggests a pluggable model where enterprises create multi-threaded supply chains when suppliers are interchangeable (see Fig. 2).

2.2.2. Collaborative planning, forecasting, and replenishment (CPFR) The CPFR model [5] for supply chain integration attempts to reduce inventory levels by stabilizing supply chain activities through close collaborations among trusted

Fig. 2. SCOR model for multi-threaded supply chains.

112

W.J. Tolone / Computer-Aided Design 32 (2000) 109–117

trading partners. This model was proposed by the Voluntary Inter-Industry Commerce Standards Organization based on Benchmarking Partners Collaborative Forecasting and Replenishment (CFAR) work. Companies such as Warner Lambert, Wal-Mart, and Nabisco have shown support for this model. The key to CPFR is for heavyweight trading partners to develop shared business plans, sales forecasts, and order forecasts as scoped by a front-end agreement that establishes expectations, non-disclosures, and process metrics. Through these shared plans and forecasts, much of the supply chain activities can be automated. Even anticipated “exceptions” to the process may be handled automatically. However, whenever fluctuations in supply or demand exceed forecasts or extend beyond the boundary of the front-end agreement, human intervention is required. These points of human intervention are referred to as collaborations within the model. 2.2.3. Collaborative, high speed, adaptive supply chain model (CHASM) The CHASM [2], in principle, adheres to many of the same supply chain processes advocated by SCOR and CPFR. At a high level this model proposes the following steps: 1. Plan supply/demand and develop order forecasts— Suppliers evaluate and select appropriate sources of demand to satisfy business objectives. Suppliers evaluate demand and develop supply, production, and distribution forecasts. Considering supply constraints, manufacturers develop order forecasts based on customer demand. 2. Prepare for demand and obtain sources of supply— Suppliers locate, negotiate, select, and schedule their supply, production, and distribution for forecasted sources of demand. Suppliers may create pre-demand inventory. Manufacturers based on customer demand obtain sources of supply necessary to meet that demand. 3. Establish actual demand—Suppliers accept orders, check availability, negotiate terms, check credit, create agreements, reserve resources, etc. in collaboration with manufacturers. 4. Fulfill demand and satisfy orders—Suppliers locate, negotiate, select, schedule, and execute their supply, production, and distribution for actual sources of demand. Manufacturers’ orders are satisfied. The CHASM model differs from SCOR and CPFR by emphasizing lightweight solutions for supply chain integration through distributed, event-based, trader-based solutions that benefit from emerging electronic commerce and web technologies. While suggesting automation at all steps, the CHASM model requires pervasive support for human intervention. That is, human interaction is needed to set up and modify the operational boundaries as well as to act as participants within an otherwise self-guiding system. In

addition, the model suggests human interaction in cases where exceptions fall outside the normal bounds of operations and the system is unable to automatically resolve the exception. Having described the landscape of manufacturing supply chains as well as underlined the importance of real-time and asynchronous collaboration support with this domain, we proceed by outlining our collaboration technology solution for supply chain integration. 3. Virtual situation rooms To adjust to the complex landscape of supply chain integration, where changes occur at ever increasing rates, manufacturers (and suppliers) require greater awareness and agility along their supply chains. However, manufacturers and suppliers increasingly have highly decentralized resources and decision making processes which challenge the requirement for timely awareness of supply chain activities, events, status information, alarm conditions, etc. Furthermore, enterprises in general are limited by primitive connectivity between people, applications/agents, technology and processes. This primitive connectivity leads to significant data and knowledge fragmentation. Manufacturers and suppliers are further hindered in their ability to incorporate application and network technology integration into their daily work practices. When such technology can be incorporated, it often has limited scalability. The unfortunate result is that enterprises are making decisions too much in isolation with inaccurate, stale, or incomplete information. The consequence is lost time, product, delivery, … and most importantly profit. Thus, any technology solution to the problem of supply chain integration must provide appropriate means for connecting people, not only with others, but also with appropriate data and applications within and across enterprises. 3.1. Vision for VSR This raises the question: what type of collaboration support is appropriate for supply chain integration? Industry traditionally takes a “reductionist” view of collaboration support. This view is very apparent in today’s workflow applications. Workflow applications view collaborative work as formal, well-defined, sequences of activities, (e.g., flowcharts). A close examination of the industry workflow reveals many successful products within the production workflow domain where the emphasis is on automated transactions across multiple applications. On the other hand, the examination also reveals very few successful products within the knowledge workflow domain. By knowledge workflow we mean applications that model the complexities of knowledge workers as they execute business practices or resolve disturbances within and across organizations. However, the efforts of knowledge workers are critical to successful supply chain integration. This is because the

W.J. Tolone / Computer-Aided Design 32 (2000) 109–117

desired automation for supply chain activities does not supplant people from these business processes but rather reshapes their participation. In other words, people and technology are complementary even when technology is used for automation [6]. Fundamentally, we believe the dearth of successful knowledge workflow applications indicates inadequate support within the workflow model for responsibility management over integrated business processes [7]. Workflow applications model activities as discrete, well-defined tasks and support their execution with only immediate situational knowledge. That is, the workflow model assumes an inputs-to-outputs approach to task completion. Within production workflow applications where the emphasis is on automated transactions across multiple applications, limited situational knowledge is often sufficient to complete integrated business processes—assuming exceptional situations do not occur! However, when exceptional situations occur, responsibility for managing such situations is not directly supported by the workflow model, otherwise they are not truly exceptions. The inadequacies are magnified when considering integrated business processes that require human intervention and possible collaborations from the outset. In these situations, while the workflow model may support responsibility management at the level of business task, limited situational knowledge may be insufficient for people to complete such tasks. Thus, an inputs-to-outputs approach (or inbox-to-outbox approach) often is an insufficient model for task completion for both anticipated and unanticipated tasks. Michael Hammer offers an excellent example that demonstrates the importance of responsibility management across integrated business processes. In his book Beyond Reengineering [8], Hammer discusses the reengineering of GTE’s process for supporting customer reports of outages. Initially, GTE supported this process by having a different “specialist” complete each significant task that comprised the process. However, after “reengineering” this process, GTE made one individual responsible for the entire process. With multiple people responsible, each at the task level, the process was inefficient. Yet, when one person assumed responsibility at the process level, even when other people completed the individual tasks, the effectiveness of this process improved significantly. The point is that application integration, as a means of business process integration, requires more than just a technical solution. Furthermore, any technology that attempts to contribute to an overall solution must respect the need for situational knowledge that extends beyond the immediate context of any one task. As Hammer put it, “Even when one person cannot perform an entire process, it is still possible to have every person who is involved in the process to understand it in its entirety and focus on its outcome.” ([8], pp. 35–36.) Unfortunately, the workflow model focuses on responsibility and knowledge at the task level instead of the process level.

113

What are the implications of this on support for human intervention and collaboration to facilitate supply chain integration? Hammer offers potential insight into this question when he goes on to say, “When people appreciate the larger context of their work they do not work at cross purposes with others engaged in the same process. When everyone has a common measure there is no need for reconciling inconsistent activities.” ([8], p. 36.) In other words, support for human intervention and collaboration must be context-based. 1 This approach to collaboration support shares many similarities with the objectives of Enterprise Knowledge Portals (EKP). The International Data Corporation (IDC) describes the currently empty application space of EKP as a part of the following taxonomy for corporate portals: 1. Enterprise information portals (EIP), which provide personalized information to users on a subscription and query basis; 2. Enterprise collaborative portals (ECP), which provide virtual places for people to work together; 3. Enterprise expertise portals (EEP), which provide connections between people based on their abilities; 4. Enterprise knowledge portals (EKP), which provide all of the above and proactively deliver links to content and people that are relevant to what users are working on in real time [11]. Thus, the primary goal of the VSR technology is to enhance current ad-hoc, limited methods and mechanisms for spontaneous, real-time communication using featurerich, industry standards-based building blocks and network protocols. The overriding objective for VSR technology is to quickly find and engage all relevant members of a problem solving team supported by highly interactive, conversational access to information and control and enabled by business processes, security policies and technologies, intelligence, and integration tools. Drawing on respected social theory and learning from the limitations of the workflow model, we suggest a more holistic approach to collaborative system development that supports business processes and practices situated within rich contextual environments. Technology capturing this holistic approach would include context-oriented support for: goals and objectives, real-time and asynchronous communication (e.g. audio–video conferencing, data conferencing, whiteboard sessions, active messages, e-mail), tools, applications, filtered data, actions, impact analyses, and the timeliness of actions. Within a holistic approach, one inherently gains the possibility for rich, multi-dimensional, evolving views of business processes and practices (i.e., synchronous vs. asynchronous, data-centered vs. application-centered vs. 1 There is a large body of social research addressing the very nature of “work” (e.g. Refs. [9,10]) that supports the context-based approach EECOMS is investigating; however, a detailed discussion of these is outside the scope of this paper.

114

W.J. Tolone / Computer-Aided Design 32 (2000) 109–117

Fig. 3. VSR server conceptual design.

communication-centered vs. action-centered, …) at varying degrees of granularity. In the following sections, we outline the VSR user view and some of the features of the VSR architecture that serve to capture this holistic approach. Unfortunately, a detailed discussion of the design and architecture for VSR is prohibited at this time due to the confidential nature of ongoing research governed by consortium non-disclosure agreements. 3.2. VSR user view The core participant interface to situation rooms is a thin and web-enabled client for ease of access and deployment. To use the VSR technology, a user visits the corporate web site and is authenticated. After authentication, the user is taken to her/his hot-list of situation rooms containing those rooms for which the user has registered interest. A hot-list, although similar to a list of book-marked web pages, also facilitates awareness of situation room alarms. That is, under each situation room in the hot-list, the user sees a sub-list of current alarms associated with the room that have occurred over the last several days/hours depending on the amount of activity selected by his installation. If no alarms are active, these sub-lists are empty. Alarms are triggered by any number of situations and vary across installations. For example, alarm triggers for supply chain activities include: sales or supply constraint violations; order, supply or demand exceptions; demand fluctuations; forecast discrepancies; late shipments; etc. When alarms occur, VSR notifies situation room observers via the notification component. From the hot-list a user can enter a situation room or display the user/situation room registry. The registry is a standards-based directory service used to browse the list of users and situation rooms on a particular VSR server and to visit other VSR servers. When visiting a situation room, a user can see a list of the other users currently “visiting” the situation room. The user

also sees a collection of tools, applications, and data relevant to the activities supported by the situation room along with support for real-time and asynchronous communication. Asynchronous support is provided via tools such as discussion forums and document attachments. Real-time support is provided via tools such as audio/videoconferencing, application sharing, shared whiteboards, and chat sessions. When real-time communication is desired, conference mode is turned on for the situation room. When entering conference mode, a real-time conference is launched for the situation room visitors using standardsbased conferencing technology. Early versions of VSR have successfully integrated with Lotus Sametime and Microsoft NetMeeting to provide this functionality. Users are automatically added and removed from the real-time conference as they enter and leave the situation room. Users can freely switch between in and out of conference mode. VSR supports multiple simultaneous situation rooms. Situation rooms may be long-lived or short-lived. Each situation room should be tailored appropriately to facilitate the desired activities of session participants. Similarly, participants should be able to configure individual participation in situation rooms as desired, subject to obvious hardware and software constraints. Users can both “observe” and “visit” multiple situation rooms simultaneously. Finally, users may be logged on to a VSR server without being in a situation room. Additional features of VSR include the ability to integrate with middleware technologies, log situation room activities, utilize authorization (access control) services, and support for situation room evolution, i.e. sessions should adapt (either automatically or upon direction) to changes in participants, software and hardware support, activity requirements, etc. 3.3. VSR architecture Adhering to the vision that situation rooms are meaningful contexts that connect individuals within and across enterprises, the architecture for VSR technology allows for new technology incorporation, legacy application/data integration, and real time conferencing within these contexts to improve user awareness of activities and connectivity. To allow technology integration and plug-n-play, the VSR server architecture is component based and layered. Fig. 3 depicts the conceptual architecture for a VSR server. This architecture is divided into three parts: the communication bus, functional components and application support. Communication among components is supported via publish/subscribe messaging. Each functional component supports a publish/scribe API to the communication bus, a function-specific interface, and an implementation of that interface (potentially to underlying application support). The application support in this diagram merely indicates

W.J. Tolone / Computer-Aided Design 32 (2000) 109–117

candidate technology groups that might be used to fulfill functional requirements. Although the confidential nature of this research precludes us from including the details of these functional interfaces here, we should make clear that as part of our VSR development efforts, we are leveraging several leading or emerging information technologies so that we can better focus our research and development efforts. In the following, we provide further discussion of two aspects of this architecture, “Notification and Presence” and “H.323 and T.120 Conferencing Support”. 3.3.1. Notification and presence The value of the VSR hinges on the ability of this application to notify and quickly assemble team members for spontaneous collaborative workgroup sessions. To make contact with all relevant team members, communicate brief details of a real-time situation and quickly schedule a VSR workgroup, intelligent on-line presence, notification and communication methods are required. Several relevant networking technologies are emerging to help deal with this problem (e.g., Lotus Sametime). These applications are capable of determining whether a team member is readily available for an on-line workgroup session, establishing a high priority, “instant messaging/ conferencing” environment, launching the appropriate applications and providing relevant information for the workgroup. In some cases, if primary notification and communication methods fail, these applications are also capable of utilizing other secondary or backup communication methods that might be appropriate as determined by each team member. 3.3.2. H.323 & T.120 Standards-based conferencing support The H.323 specification, approved in 1996 by the ITU’s Study Group 15, defines a standard for video conferencing that is broad in scope, and includes both stand-alone devices and embedded personal computer technology as well as point-to-point and multi-point conferences. The standard addressees call control, multimedia management, and bandwidth management for point-to-point and multi-point conferences. H.323 also addresses interfaces between LANs and other networks. H.323 can be broken down into four major components for a network based communication system. They are the Terminal, Gateways, Gatekeepers and Multi-point Control Units (MCU). H.323 is part of a larger series of communications standards that enable video conferencing across a range of networks. Known as H.32X, this series includes H.320 (for ISDN networks) and H.324 (for POTS or PSTN) communication. Data conferencing is an optional capability of H.323. When supported, data conferencing enables collaboration through applications such as whiteboards, applications sharing, chat and file transfer. H.323 supports data confer-

115

encing through the T.120 specification. An ITU standard, T.120 addressees point-to-point and multi-point data conferences. It provides inter-operability at the application, network and transport level. An H.323 system can support data by incorporating T.120 capabilities into clients and MCU. The MCU controls and mixes data conferencing information. The T.120 standard contains a series of services as well as communication and application protocols that provide support for real-time, multi-point data communications. T.120, as a set of standards, may act alone or in concert with one of the H.32x standards. As such, the T.120 standards include many similar features and functions as the H.32x standards and must be able to work in conjunction with an H.32x standard. Applications are emerging that conform to these standards and show promise towards meeting the conferencing needs of the VSR technology (e.g., Lotus Sametime and Microsoft NetMeeting). 4. Example VSR use-case For the following scenario, imagine the user is an engineer. This engineer might have one or more situation rooms that he is using to support design activities. Consider the situation where the engineer is notified of a problem with a particular machine component. This engineer within the context of a situation room may consult with other engineers to redesign the component. As a consequence the engineer may need to contact the corporate procurement department as well as a part supplier to discuss the component redesign. Using the VSR technologies, such consultations can occur more easily and expediently because the engineers, procurement managers, and suppliers share a rich work context that allows them easy access to real-time collaboration technologies and provides better awareness of urgent or emerging situations via support for presence and notification. (See Fig. 4.) 5. Project status Research and development on VSR began in January 1998. At the halfway point of the three-year project, we have successfully demonstrated at least partial solutions to all of the functionally outlined in the Section 3.3 except for workflow support. To validate our solution (and philosophy for collaboration support), we have scheduled pilot deployments at several EECOMS partner sites. The first deployment will complete in Spring 2000. 6. Related work The requirements and design for the VSR technologies cut across many technology domains. Thus, we choose to

116

W.J. Tolone / Computer-Aided Design 32 (2000) 109–117

Fig. 4. Example use-case for VSR technology.

highlight that work which is most closely aligned with the vision for VSR. Each of the following projects is similar to VSR in that it provides some notion of collaboration support that is arguably context-based. However, VSR differs from these projects in at least three important aspects: 1) VSR is standards-based, 2) VSR is designed for greater degrees of system integration, 3) VSR’s holistic approach we believe will lead to richer notions of context and greater user and system awareness. WORLDS-ORBIT [12–14] addresses the need for computer assistance to human problem solving in a complex, information-rich environment. In WORLDS-ORBIT, such assistance is provided via zones. A zone is characterized by: • the primary work activity/activities for which the zone is constructed or for which it is being used; • the particulars of the zone (i.e., the artifacts, data, tools, actions, etc. that tailor a zone to its use or purpose); • the people who participate in, and interact with, the zone; and • the processes which exist or arise within and among zones. INFOSPHERES [15] also focuses on providing complex, information-rich environments for collaborative problem solving. The notion of an infosphere appears to be very similar to that of a zone. Other systems that use the room metaphor to provide session-based collaboration support include: • TeamRooms [16] provides real-time and asynchronous support for meetings, document sharing, and inter-

group communication. A team room is very similar to any early design of the WORLDS-ORBIT zone called a locale. [17] • CommonPoint (described in [18]) supports a people, places, things metaphor to support distributed shared documents. • Both DIVA Virtual Office Environment [19] and the GroupKit’s Rooms session manager [20] used the rooms metaphor as a mechanism for collecting and managing people and related data. • CAVECAT media space [21] established audio-video connections whenever one user entered a room where another user was present.

7. Conclusions As we raised at the outset of this paper, to be competitive, enterprises must integrate their supply chains more effectively and forge close memberships with customers and suppliers more quickly. Consequently, technologies must be developed that enable enterprises to respond to consumer demand more quickly, integrate with suppliers more effectively, adapt to market variations more efficiently and evolve product designs with manufacturing practices more seamlessly. As such, the mission of the EECOMS coalition is to research, develop, and demonstrate technologies to enable the integration of manufacturing applications in a multicompany supply chain planning and execution environment. Although the coalition is targeting three technology areas that it believes are critical to the success of this mission, in

W.J. Tolone / Computer-Aided Design 32 (2000) 109–117

this paper we presented the project’s early efforts to develop technology to connect people across enterprise boundaries. We believe real-time and asynchronous collaboration technology will play a critical role in allowing manufacturers to increase their supply chain agility. We are realizing our efforts through our VSR technology. The primary goal of the VSR technology is to enhance current ad-hoc, limited methods and mechanisms for spontaneous, real-time communication using feature-rich, industry standardsbased building blocks and network protocols. VSR technology is being designed to quickly find and engage all relevant members of a problem solving team supported by highly interactive, conversational access to information and control and enabled by business processes, security policies and technologies, intelligence, and integration tools. At the writing of this paper we are concluding the eighteen months of the three-year EECOMS project. Initial feedback to the project on early versions of the VSR technology is very positive. Acknowledgements This project is funded by the U.S. Department of Commerce NIST/ATP Technology for Integrated Manufacturing Application (TIMA) initiative under agreement 70NANB7H3042 and supported by the members of the Extended-Enterprise Coalition for Integrated Collaborative Manufacturing Systems (EECOMS) which include: BAAN/ SCS, Boeing, EnvisionIt Software, IBM, IndX, Scandura, TRW, and Vitria Technology. References [1] Computer World, January 1997. [2] Whittle BD. CHASM and the paper clip economy: a model for collaborative, high-speed, adaptive supply-chains. EECOMS Project Document, 1998. [3] Extended-Enterprise Coalition for Integrated Collaborative Manufacturing Systems (EECOMS). Available at: www.ciimplex.org. [4] AMR Supply Chain Council available at: www.supply-chain.org. [5] VICS CPFR available at: www.cpfr.org. [6] Billings C. Aviation automation: the search for a human-centered approach. Mahwah, New Jersey: Lawrence Erlbaum Associates, 1997. [7] Tolone WJ, Chu B-T, Long J, Wilhelm R, Finin T, Peng Y, Boughnnam A. Supporting human interactions within integrated manufacturing systems. International Journal of Agile Manufacturing 1998;1(2):221–34. [8] Hammer M. Beyond reengineering. New York: Harper Business, 1996. [9] Suchman L. Plans and situated actions. Cambridge: Cambridge University Press, 1987.

117

[10] Strauss A. Continual permutations of action. New York: Aldine De Gruyter, 1993. [11] PRNewswire, March 1999. [12] Tolone WJ, Kaplan SM, Fitzpatrick G. Specifying dynamic support for collaborative work within WORLDS. In Proceedings of the ACM 1995 Conference on Organizational Computing Systems, 1995, August 13–16, Milpitas, CA, p. 55–65. [13] Kaplan SM, Fitzpatrick G, Mansfield T, Tolone WJ. In: Rees M, Mansfield T, editors. Shooting into orbit, Proceedings Inaugural Australian National Symposium on Computer-Supported Cooperative Work, August. Brisbane, Australia: DSTC Pty. Ltd, 1996. p. 38–48. [14] Tolone WJ. Introspect: a meta-level specification framework for dynamic, evolvable collaboration support. PhD Thesis, University of Illinois at Urbana-Champaign, 1996. [15] Compositional Research Group. Caltech Infospheres Project. Available at www.infospheres.caltech.edu. [16] Roseman M, Greenberg S. TeamRooms: Network Places for Collaboration. In Proceedings of the ACM 1996 Conference on Computer-Supported Cooperative Work, 1996, November 16–20, Cambridge, MA, p. 325–33. [17] Fitzpatrick G, Tolone WJ, Kaplan SM. Work, locales and distributed social WORLDS. In Proceedings of the Fourth European Conference on Computer Supported Cooperative Work (ECSCW ‘95), 1995, September 10–14, Stockholm, Sweden, p. 1–16. [18] Orfali R, Harkey D, Edwards J. The essential distributed objects survival guide. New York: Wiley, 1996. [19] Sohlenkamp M, Chwelos G. Integrating communication, cooperation and awareness: the DIVA virtual office environment. In Proceedings of the ACM 1996 Conference on Computer-Supported Cooperative Work, October 22–26, Chapel Hill, NC, 1994, p. 331–43. [20] Roseman M, Greenberg S. Building real time groupware with groupkit, a groupware toolkit. ACM TOCHI, 1996, March. [21] Mantei M, Baecker R, Sellen A, Buxton W, Milligan T, Wellman B. Experiences in the use of media space. In Proceedings of ACM CHI, 1991.

William J. Tolone is an Assistant Professor in the Department of Computer Science at the University of North Carolina at Charlotte. He is also a member of the faculty of the School of Information Technology at the University of North Carolina at Charlotte. Dr. Tolone received his B.S. in both Computer Science and Mathematics from Millikin University (Decatur, IL) in 1989 and his Ph.D. in Computer Science from the University of Illinois at Urbana-Champaign in 1996. He has researched for nine years in the area of collaborative systems and for three years in the area of systems integration. Dr. Tolone has directed projects funded by the National Institute of Standards and Technology (NIST), the National Science Foundation (NSF), and the IBM Corporation. He has been a contributing researcher on projects funded by the Defense Advanced Research Projects Agency (DARPA), the Army Corps of Engineers, Fujitsu/OSSI, the Intel Corporation, Solectron, NIST and NSF. Dr. Tolone’s research interests are in the areas of computer-supported cooperative work, groupware, enterprise integration, electronic commerce, object-oriented design, agent technologies, meta-level architectures, specification environments, and software engineering.