Igor Hawryszkiewycz, School of Computing Sciences, University of Technology Sydney, PO Box 123, Broadway NSW 2007, Australia, igorh@socs.uts.edu.au
This paper describes trends in electronic commerce to support knowledge sharing across enterprises, such as for example, supporting cross functional teams usually working across distance on the development of new products and services. It sees knowledge sharing processes as primarily emergent, and that such processes require support tools that allow users to easily set up new collaborative arrangements while maintaining awareness across the enterprise. The paper describes the requirements to be met by toolkits and then describes a toolkit known as LiveNet for that supports these requirements.
Electronic commerce is a rapidly evolving area that is continuing to penetrate into new application areas. Early systems emphasized transaction based applications found in EDI or Web Based ordering and purchasing systems. These were followed by the more groupware oriented applications emphasizing workflows and document management. Current evolution is to emphasize more personalized services and generally falls in the realm of knowledge management and sharing. They include areas such as organizational learning, formation of focused multi-function teams to address problems or create new products and services, the building of communities and alliances, experience transfer, development of task and process knowledge, or forming common ground on which further work can be based.
The knowledge sharing processes differ from many existing processes in that they emerge rather than being predefined. They are generally opportunistic in nature, result in disconnected and parallel work that must nevertheless be guided to a common goal. Because of this difference, emergent processes require new modeling methods and technologies to build systems that support them. The modeling methods and technologies to support emergent processes no longer emphasize the more defined workflows that characterize traditional processes. What is needed are groupware supported systems that dynamically evolve with process needs, rather than mapping from a predefined model. The goal of modeling now takes a new meaning in that it identifies the generic terms to describe emergent processes. Such terms are then directly implemented as menu commands and components in groupware toolkits, which are used to dynamically specify new work units and collaboration between them. The four major requirements that must be met by such toolkits are:
Most workspace systems support a subset of such requirements. Many emphasize searches and management of information, which centers on collecting all related knowledge within the one workspace. Most of them still require users to devise the processes through which information is shared and interpreted to produce new products.
The work described in this paper describes a toolkit, LiveNet, being developed to show how one toolkit can meet all of the above requirements and illustrate the feasibility of doing so the innovation process (Kuczmarski, 1997) an example. It is based on a set of general modeling terms (Hawryszkiewycz, 1997) that describe emergent processes and supports commands based on these terms through shared workspace systems. The paper will also outline the collaborative database support for this toolkit. Before doing so the paper will describe requirements in more detail and the way they are supported by LiveNet.
The four major requirements that must be met by toolkits that support emergent processes are:
So far, most toolkits for this domain have concentrated on only some of these four major requirements. Thus there are descriptions of tools that provide shared editing tools, but emphasis on awareness is primarily through synchronous work. There are also tools that maintain awareness in predefined systems based on workflow management. Work on integrated workspaces is best exemplified by current commercial groupware. Examples include LinkWorks (http://www.digital.com/linkworks/) or Livelink (http://www.opentext.com/livelink/), which primarily concentrate on concrete operations concerned with documents. Interworlds (http://www.interworld.com) also provides a set of tools to set up and administer workspaces. The operations of assembling teams and information sources and fitting them together in such systems are left to individuals to do manually without any assistance. Although this supports the idea of opportunistic and disconnected work it provides little assistance in monitoring and directing the disconnected parts to a common aim. This is also left to the users by providing facilities such as notifications, or discussion systems.
The goal of this research is to show that is possible to provide toolkits that integrate these four major requirements. It is also to provide an interface to allow users to define work processes directly rather than through an intermediate language (Dourish, 1998). This is demonstrated by the prototype toolkit, LiveNet, which can be found on:
http://138.25.8.237/ks/Default.html
(On entry use 'visitor' for user name and password. A Java enabled PC with access to Netscape Communicator 4.5 or Explorer 4.0 is preferred. Only a limited set of menu options is available to visitors).
Its major components and the semantic framework are described in the following sections.
Perhaps one of the most important requirements of a general toolkit is that it should be based on generalized terms. Higher level terms such as communities, activities and artifacts have often been used. So has the idea of roles. Detailed analysis has identified additional terms (Hawryszkiewycz, 1997). The major terms used here are roles that carry out tasks. Tasks usually effect changes to artifacts, be they documents or other physical elements. Roles are principally responsibilities that are assigned to actors, who are people in the organization. Examples of roles in software engineering include designer, or programmer or project manager. Artifacts may be user requirements, system specifications, design documents or program modules themselves. In innovation typical roles may be marketing manager, review member or external expert. Examples of tasks are to assure quality of a program, or develop a program, or validate program against requirement. Thus a role, programmer, may be assigned the task of developing a program and may use the artifacts, design document and program.
The way that people in roles communicate and work together is described by interactions. Interactions in fact become the detailed decomposition of activities that were defined by the top level rich picture during planning. Each interaction is made up of a group of roles carrying out some action on some artifact. Examples include a meeting to make a decision, a joint preparation of a document such as a specification, or simple exchange information.
Processes emergence is modeled as the creation of new transitions between interactions, or through the creation of new interactions, or even creation of new activities. Thus any of the roles can be designated to set up a new collaborative service, assign people to it and make artifacts available within the service. The designated role can also authorize roles to carry out designated actions. We now describe a toolkit that supports such workspaces.
LiveNet allows users to compose workspaces in terms of generic concepts (Hawryszkiewycz, 1997). It can be used to dynamically create new workspaces to meet new opportunities and includes ways to maintain communication and awareness between these workspaces. It can bring together large groups in one workspace, and provide distributed rather than central governance to coordinate their activities. Workspace owners are free to "invite" any participants into the workspace, set up processes, delegate process actions to participants, and create new workspaces as needed, often along organizational lines.
The support provided by the LiveNet includes:
Figure 1 illustrates the top-level interface provided by LiveNet. This interface is an example of central administration for the innovation process. Its goal is to evaluate new ideas and decide which of these should be considered for further in-depth evaluation. It determines the milestones and strategic screens that define the questions to be used in the evaluation. The interface provides a menu to bring up the components of the workspace as separate windows. It allows users to dynamically change these components and create new workspaces as needed. A new workspace with this interface can be created using LiveNet menus in a matter of minutes.
Figure 1 - The top level LiveNet interface
A workspace contains the following major windows, some of which as shown in Figure 1:
The System' menu is used to create new workspaces when necessary. The remaining menus are used to compose the workspace. It includes ways to create any new objects in the major windows and assigning them to roles as determined by the governance structure. Thus only selected roles may be able to add new objects to the workspace, or access existing objects. It also allows objects in one workspace to be made available in other workspaces. LiveNet also provides ways to manage governance by assigning different menu selections to different roles through the 'Assign to role' menu selection in the 'System' menu.
The 'People' menu provides the ability to create roles and assign participants to the roles. The 'Documents' menu provides the ability to add new documents and make them available to roles. The 'Things to do' menu allows actions to be created and assigned to roles. Discussions are also made available to roles through the "things to do' menu. Each role can be assigned a different menu within each workspace to provide the necessary governance control.
New members can be invited quite easily by selecting a participant in the 'People' menu and assigning them to a specific role. Governance structures within the particular communities are supported in two ways. One is that roles can be restricted to a subset of menu commands. The other is that roles can be restricted in their access to objects. Thus in Figure 1, only some roles could be assigned to set new ideas.
It is possible to create new workspaces when the need arises. For example, a decision to pursue an idea, 'idea-1', in depth leads to the creation of a new workspace to do so. Figure 2, shows this additional workspace. The original administration 'innovation' workspace is also shown in Figure 1 together with the new workspace. The new workspace contains the roles and actions needed to make the detailed evaluations.
Once the pursue idea workspace is created, it can itself create new workspaces to support interactions between individual people involved in evaluation an idea. The management interface can set up any number of workspaces, each one pursuing a different idea. Thus the process can gradually emerge.
Figure 2 - A New Workspace
The typical scenario in creating new workspaces, usually follows the following steps:
Step 1 Define a workspace, for example, to pursue a
selected idea.
Step 2 Add artifacts to the workspace, say, innovation
strategy and marketing strategy,
Step 3 - Define roles within the workspace, for example, lecturer,
tutor and student,
Step 4 - Assign participants to roles,
Step 5 - Define discussions and actions allowed in them,
Step 6 Assign the actions to the roles.
The third and fourth requirements awareness and generic operation for knowledge sharing and process management, are met through a general discourse system that can be customized to support the data and discussion structures used to maintain awareness, and for milestone management and knowledge sharing. As shown in Figure 3, each workspace has a forum, which can contain any number of discussion blocks. These discussion blocks can then be accessed through actions in the action menu of a LiveNet interface. The actions are assigned to roles consistently with the governance structures.
The ability to assign the actions to selected roles is provided to provide the necessary moderation and facilitation needed to ensure that the tacit knowledge of relevant experts is brought to bear on relevant issues.
Figure 3 - Workspaces for innovation processes
Figure 3 illustrates the way of organizing the forums. There is a separate forum for each workspace. The forum is made up of a number of discussion blocks, as for example, 'Milestones', 'Discussion'; and 'Terminology' in workspace 1. A number of actions are created in the forum to operate on these blocks. These actions are allocated to roles in ways accepted by the governance structure. Thus 'Manager' can comment on discussion and set milestones. The 'Market-analyst' can comment on discussion and clarify terminology. Other actions can restrict some roles to only view particular blocks or act on selected statement types in the block. Access to blocks in one forum can be shared between workspaces to support collaboration between them. Thus access to terminology is shared between workspaces 1 and 2 in Figure 3.
Our goal is to extend the forum structure to support general actions that take place in awareness, milestone management and knowledge sharing actions. This requires flexible structures for the blocks that make up the forum so that they can be customized to a variety of requirements. For this reason, the discourse system will support a range of statement types that can be combined and for discourses to be moderated through actions associated with each discourse type.
These discourse blocks can be adapted to the kinds of services needed to maintain collaboration within and between workspaces the workspace. Within a workspace it is possible to set news services and frequently asked questions. In addition blocks to keep track of surprises and goals, together with milestone structures that track workspace activities. Using discussion blocks for this purpose allows goals and milestones themselves change through discussion between the roles. Moderation can be used to give different roles different abilities to take special responsibilities here, as for example setting milestones.
Awareness and coordination between workspaces is achieved through sharing of discussion blocks as shown in Figure 3. Thus for example a group of workspaces can share the same milestones or terminology. They can also share informal discussion through discussion blocks.
Some lower level operations to do thus are also integrated in the workspace, including:
Informing roles of changes through notifications,
Creating and entering discussions,
Searching for and collecting documents,
Information filtering.
It is increasingly realized that knowledge sharing will need a more work-centric rather than communications approach that combines all of the technologies, which will be integrated into Intranets. The kinds of work-centric activities found in knowledge sharing include development of consistent terminologies, sensemaking, interpretation and evaluation of proposals within a distributed enterprise wide basis. Support for knowledge sharing requires modules to assist defining a common terminology, forming shared perspectives (Boland and Tenkasi, 1995), interpreting and transferring knowledge between thought worlds (Dougherty, 1992) to construct new objects, and evaluating such propositions against goals. Moderation is needed to support sensemaking and interpretation, etc. in structured ways, by assigning responsibilities to people for well-defined aspects of knowledge work.
Support for knowledge sharing must combine discourse systems with the kinds of operations used in knowledge sharing. Boland and Tensaki (1995) define a number of different kinds of discourse types that can be used for this purpose. Knowledge sharing imposes other requirements in that users can be provided with evaluation screens on which to comment on ideas. These again contain alternate proposals with designated users allowed to raise and comment on the proposals. The block currently provided assists users to maintain a consistent terminology. There are also a number of commands being provided through the action selection. Thus, for example, processes used in sensemaking concern framing positions requiring tools such as text analysis. Our goal is to combine the forums with such tools.
Discourse blocks for knowledge sharing are provided within the workspace network to allow responsible people to set up a forum of discussions to encourage effective use of knowledge. Each such forum is made up of a number of related discussions. Forum owners can delegate responsibilities for these discussions. They can define norms for workspace participants specifying how ways in which they can interact with each other. Furthermore, some participants may appear in more than one workspace. They may however have different responsibilities, or roles, in each workspace. In some, they may only view some discussion databases, and comment on issues whereas in others they may raise issues. Facilitators can be defined to coordinate FORUMs discussions on further elaborating on the knowledge needs accessing the relevant workspaces that provide relevant expertise to make sense of the knowledge within the business unit context.
Our current research is towards using agents to support work within the network. The agents have the knowledge of how to maintain awareness and milestones and can assist users to set them up while creating workspaces. Software agents can assist users in such environments in a number of ways. Agents within workspaces can identify incoming messages, and trigger plans based on their belief of what should be done about each message. The plans themselves can include communication with other agents (through workspace messages) and signal their intention through the customization of available services and making commands available through the interface (Hawryszkiewycz, Debenham, 1998). The first step here is to assist in setting up workspaces, including location of team members and selection of collaborative services. Agents can also support coordination of parallel and disconnected processes through monitoring the activities in these workspaces.
The paper demonstrated the feasibility of building a toolkit that
can meet the main requirements of emergent processes.
Igor Hawryszkiewycz, © 1999. The author assigns to Southern Cross University and other educational and non-profit institutions a non-exclusive licence to use this document for personal use and in courses of instruction provided that the article is used in full and this copyright statement is reproduced. The author also grants a non-exclusive licence to Southern Cross University to publish this document in full on the World Wide Web and on CD-ROM and in printed form with the conference papers and for the document to be published on mirrors on the World Wide Web. This assignment does not apply to the LiveNet system that is described and illustrated in the paper.