AWARENESS MODELLING AND ITS APPLICATION IN COOPERATIVE NETWORK MANAGEMENT

Farhad Daneshgar+ and Pradeep Ray*

+Basser Department of Computing Science, University of Sydney, Australia,

Tel: +61 2 9351 4922,

*School of Information Systems Technology and Management, University of New South Wales, Australia, Tel:+61 2 9385 5890,

1

1

ABSTRACT

Although communication among the collaborating workers in business processes has always been an important issue to business organisations, there is no measure for the effectiveness of collaboration. This paper presents a model based on “Awareness Levels” to measure the level of cooperation amongst different human roles in a business process. The hypothesis is that collaboration among various roles within an enterprise environment is improved by maintaining the awareness levels of individuals at its desired level. This paper illustrates the awareness model through its application in a large telecommunication service provider organisation. According to this study, the awareness model seems to be able to explain some problems of cooperation in this business environment. Since the model is abstract in nature, it can be applied in different organisations and businesses.

1. INTRODUCTION

Effective management of networks and systems requires cooperation of people within and across organisations [Dev 93], [Ray 99]. While there has been substantial progress in the modelling and presentation of management information, there is not much research reported on the human face of the network and systems management. We call this “cooperative management”. [Sachs 95] highlights the importance of support for human sociological, psychological, and organisational factors in a help-desk based cooperative management environment. This paper presents cooperative management from the perspective of Computer Supported Cooperative Work (CSCW).

Measuring human cooperation has been a focus of international research in CSCW [Benford 95], [Palfreyman 96], [Rodden 96]. This measure is called “awareness”. This paper introduces an improved model for cooperative management of networks and systems.

The paper starts with a brief description of an awareness model [Daneshgar 98]. This model is illustrated briefly in Section 3 with graph theory constructs. Section 4 presents a study of cooperative management in a real organisation in a help-desk based trouble-ticketing environment. We try to explain some shortcomings in this environment on the basis of awareness levels. And finally, in Section 6 we discuss potential benefits of this model for applications in different business processes.

2. A COLLABORATIVE AWARENESS MODEL

This section presents a collaborative awareness model that has applications in a wide variety of business environments. Some of the questions addressed are:

(i) In what way, and under what circumstances, an "enhancement in communication among collaborative workers in business processes" will produce the highest benefit to an enterprise?

(ii) Is there a universally accepted definition for the term "enhancement of communication in business processes"?

(iii) What will be the cost of implementing various communication strategies for enhancing communication in business processes in order to obtain the same results? Obviously, unless an agreed upon definition for "communication in business enterprises in a collaborative context" exists, the question of "cost" can only be answered in a subjective manner.

(iv) How to define/measure the "awareness" of collaborators in a collaborative business processes?

2.1. Towards a General Theory of Process Awareness

Many definitions currently exist for the term 'awareness' within the field of CSCW (see [Bannon 91], [Fuchs 95], [Dourish 92], and [Benford 94]). The foundation of the proposed model is based on the role-interaction approach to awareness, partly discussed by Dourish. According to this definition, " ... participants inform each other of the activities they perform" [Dourish 92]. Our proposed definition is based on the following set of collaborative semantic concepts:

Task - what must be done in order to produce outcome.

Roles - assignments made to agents for carrying out tasks.

(Collaborative) Process - a union of one or more sets of related tasks, a set of roles which perform these tasks, and a set of artefacts that are used by the roles for achieving a distinct organisational goal/objective called process goal. Process goal, on the other hand, is defined as the long-run position the process within the organisation seeks to occupy and the specific performance targets management seeks to achieve in pursuing the process (the latter definition is adopted from [THO84]).

Artefact - a passive object which is used (that is, exchanged/created/shared etc.) by/between the roles during execution of their tasks.

Task dependency. Task dependency between the two tasks (and therefore, between the two roles, since tasks are performed by these roles) exists when a single artefact is used/shared by these two roles in order to perform their tasks.

Based on the above set of semantic concepts, the following definition of awareness is proposed.

Awareness is an individual's perception of:

 a knowledge, gained by a human role (actor), about all the objects that lead the role to an understanding of all the tasks that s/he must perform within the process. This is referred to as level-0 awareness which is the lowest level of awareness an individual requires within a business process. An awareness lower than this will disqualify the role for participating in a collaborative business process.

 a knowledge about all the objects that lead the role to an understanding of all the related roles within the process (level-1 awareness).

 a knowledge about all the objects that lead the role to an understanding of all the roles within the process (level-2 awareness).

 a knowledge about all the objects that lead the role to an understanding of all interactions between all the pair of roles within the process (level-3 awareness).

 a knowledge about all the objects that lead the role to an understanding of how everything fit together to make the process (level-4 awareness).

The above definition provides foundation for a framework which, in turn, can facilitate communication among collaborative workers within business processes. According to the proposed definition, 'awareness' is regarded as a measurable knowledge associated with the roles in a cooperative process. It is defined in terms of levels; the higher the level, the more aware the individual will be in a collaborative context. Initially five levels of awareness have been identified.

2.2. Graph Theory Illustration

This section presents the awareness model from the perspective of graph theory.

A Collaborative Process Graph (from now on called the 'G graph') is a simple connected graph that represents a distinct business process, and consists of a non empty set of role and task vertices called role(x) and task(x,i) respectively (where 'x' is the identity of the role and 'i' is the identity of the task which is carried out by the role), and a set of undirected pairs artefact edges in such a way that there is a path between every pair of distinct vertices of the graph. A path of length 'n' from any vertex 'X0' to any other vertex 'Xn' is a sequence of edges E1, E2 ..., En on the graph such that:

E1 connects X0 and X1

E2 connects X1 and X2

E3 connects X2 and X3

.

.

.En connects X(n-1) and Xn

Edges in the G graph represent artefacts and are used by roles to perform different tasks. There are two kinds of artefacts in the G graph. One which has a role and a task as its endpoints and can be expressed by the set {role(x),task(x,i)} and is called role artefact; and the other kind which has two related tasks as its endpoints, is used/exchanges by/between two roles when performing their related tasks and is expressed by the set {task(x,i),task(y,j)} and is called a task artefact. Task artefacts are specifically important in collaborative business processes because they reflect interactions among the roles. Role artefacts are important because through these artefacts a role can share his/her knowledge in different processes An artefact/edge is incident on each of its endpoints, and two artefact/edges incident on the same endpoint are called adjacent. Two vertices 'u' and 'v' are also adjacent (or neighbours) if the set of {u,v} is an artefact/edge of the G graph.

The degree of each role(x) vertex represents the number of tasks that role(x) performs. The degree of each task(x,i) vertex represents the number of other tasks that are dependent on the task(x,i), plus one.

Two roles 'x' and 'y' within a process are dependent if there exists at least two task vertices task(x,i) and task(y,j) which are adjacent.

An edge with just one endpoint is called a loop which is adjacent to itself, meaning that an artefact is used either by a task or by a role in a non-collaborative manner. Artefacts with the same set of endpoints are said to be parallel, meaning that more than one interaction is occurring between the same endpoints

For simplicity, it is assumed in this thesis that each artefact is unique within the G graph. Such uniqueness is reflected in the fact that each vertex within the G graph is uniquely identifiable, and so is any pair of vertices within the G graph.

The set of all task artefacts (that is, {task(x,i),task(y,j)}) in each process represents theTask Dependency Map for that process.

Figure 1 shows a G graph consisting of two processes. The first process has roles X, Y, T and V, and the second one has only one role, Z. The first process is a collaborative process since there are at least two roles with task dependency, whereas the second process is not collaborative yet, since there is only one role in it, and therefore no task dependency exists in it. In this figure, hashed circles represent role vertices, and other circles represent task vertices. Thick straight lines represent role artefacts {role(x),task(x,i)} and narrow straight lines represent task artefacts {task(x,i), task(y,j)}. In the first process, there are two roles with degree of four (ie, X and Y), two roles with degree of three (ie, T and V), and one role with degree of one (ie, Z). The degree of task '1' is two which means this task is connected to one other task within the process (that is, task 'd'); whereas the degree of task '6' is 3, meaning that this task is dependent on two other tasks: tasks '4' and 'b'.

Figure 1: An enterprise collaborative graph with two processes

Figure 2 shows the 'task dependency' map for the process on the top of the G graph using dotted lines. Each dotted line is called task dependency path/walk. There are two such paths for this process which indicates that although the process is collaborative (that is, a connected graph) however, not every role has task dependency with every other role within the process.

The task dependency map (or TDM) of the first process can be shown by a set task dependency paths as follow:

TDM = {{a,b,c,d}, {e,f,g,h}}.

(Note that an alternative method of representing a path is by its vertices)

Figure 2: 'Task dependency map'.

2.3. Awareness Levels

These levels are shown in Figures 3 to 5 by dark regions on the graph. For example, Level-0 awareness for role X consists of the vertices 1, 2, 3 and 4 plus all the artefacts/edges that connect these vertices together. Awareness level-1 for the role X in Figure 4 consists of the following objects: 1, 2, a, b, c, d, e and g as well as all the edges that connect these vertices together.

Level-3 awareness describes the context of knowing all the interactions that occur between any pair of roles within the process. This awareness can be captured by accessing all the task artefacts that are exchanged between any pair of roles within the process. In this particular example, levels 2 and 3 awareness for the role X are the same, and therefore one graph is used to show both.

While levels 0 to 3 awareness differ between individuals, level-4 awareness is the same for all the roles. This level of awareness is the entire G-graph; that is, it incorporates all the objects on the G-graph. For more details about various aspects of the model refer to [Daneshgar 98].

Figure 3. Representation of level-0 Awareness of role X

Figure 4. Representation of level-1 awarenessof role X

Figure 5. Representation of levels 2 and 3 awareness of role X

3. RESULTS OF REAL ORGANISATIONAL STUDY

3.1. Troubleticketing Environment

In this study, we examined a number of real-life scenarios that indicate problems in a trouble-ticket environment in a large telecommunication organisation, as reported by people working in the organisation. This is a help-desk based network management process called trouble-ticketing. In this case, management personnel cooperate to manage a problem using various network elements. Whenever there is a problem, the customer reports that to the help-desk. The operator then assigns a trouble-ticket to the problem and assigns to an appropriate technical person. This person tries to solve the problem and escalates alarm (calls EXPERT) if the problem can not be solved within the stipulated time. The trouble-ticket is closed once the problem is resolved to the satisfaction of all concerned [Johnson 92].

We now consider a scenario of cooperative network management in a telecommunication service provider. This is based on a real study in an Australian telecom carrier. The scenario may be described as

The Sydney to Perth wide area link, which is on an existing 2 Mbps link on a lower version NTU, needs to be upgraded to a higher version NTU. For this an outage of 30 minutes is required.

In this case the human roles involved are:

1. The Change Manager is responsible (on behalf of the telecom organisation under study) for successful operation of the given changes in the given set of user organisations.

2. The Technician at the Network Management Centre is responsible for the technical aspects of this change.

3. The Operator at the Help-Desk is responsible for procedural communication amongst all concerned, and updates the repository available for this purpose.

4. The User(s) represent contact persons in the user organisations where the change is being undertaken.

Arrows of interaction show the direction of human communication. We now describe the scenario in terms of some numbered interactions shown in figure 7

3.2. Scenario Analysis

The given scenario involves the following interactions amongst roles defined in the previous section.

  1. The Technician discusses with a remote Test Coordinator about a suitable time. This task has adequate tool support in the organisation understudy.
  2. The Technician places change request with proposed time and user impact statement to Change Manager . The change impact statement requires considerable amount of context knowledge regarding user configurations. In the absence of an automated facility, the Technician is not likely to have this information concerning user activities and needs. As such this person is only at level-1 of awareness with existing artefacts and tools. In order to be effective this person should be at level-3. This can be achieved by access to appropriate repositories to support interactions at this level.
  3. Change Manager takes up with the affected Users. While the User need not be at a higher level of awareness, the Change Manager needs to have adequate level of awareness through appropriate repositories non-existent in this case. Users are totally unaware of the overall system
  4. Related Users discuss impact and examine proposed time. For this interaction to be successful, all users need to have a reasonably high level of awareness about their own system and requirements. The coordinating User knows a little more than others who are ignorant. This may require both adequate group communication mechanisms and repositories for all users to interact effectively.
  5. User resubmits request to Change Manager with possibly an altered schedule. Due to the lack of adequate level of knowledge, users may have taken invalid assumptions. The change manager also is unable help in this situation. This can waste substantial amount of time for all concerned.
  6. Change Manager issues Permit To Work to all concerned. The lack of awareness on part of change manager may lead to missing some parties concerned with the work. Also some users may not appreciate the need for responding within the stipulated time. All this may cause substantial damage to the organisation’s interests.

Obviously, each interaction requires a set of awareness for the roles. Failure to provide them may lead to dissatisfaction. In order to explore the linkage between supported awareness and satisfaction levels, we interviewed users in the organisation under study for satisfaction levels for all interactions. The following table shows the required awareness levels and satisfaction levels for each interaction.

1

1

Interaction / Awareness Required / Awareness
Supported / Awareness Gap / User Satisfaction level
1 / 1 for each role / 1 for each role / No / 8 (High)
2 / 3 and 2 / 1and 2 / Yes / 3 (low)
3 / 4 and 1 / 3 and 0 / Yes / 3 (low)
4 / 3 for each role / 1 and 0 / Yes / 3 (low)
5 / 3 and 4 / 1 and 3 / Yes / 3 (low)
6 / 4 and 3 / 3 and 1 / Yes / 2 (low)

Table 1. Awareness Modelling for the Network management Scenario

1

1

In this table we describe the awareness levels for pairs of roles in each interaction. Each interaction has two associated awareness levels for its two roles. For example, in the above scenario, interaction 2 requires awareness level 3 for the Technician, and level 2 for the Change Manager. Therefore, the awareness level is specified as '3 and 2'. The column on awareness gap shows the existence of awareness gap between the desired levels (in column 2) and the actual levels (in column 3) for every interaction. Satisfaction levels (scale 0-10) are shown for every interaction, recorded on the basis of interviews with real operations people in the organisation under study.

This table shows a direct relationship between the awareness gap and the satisfaction levels in the sense that interactions with lower that required awareness levels have lower satisfaction levels. On the other hand, the interaction with support for the right level of awareness has high satisfaction level. Designers of enterprise network management systems can now work on the right type of cooperation support for these interactions. This result was observed in a number of scenarios studied by us in this organisation [Ray 99].