ISSN 1479-4411

First published
in 2003


Electronic Journal of Knowledge Management

   

Paper 1 - Issue 1
   

Home Papers in Current Issue Previous Issues Site Map

    .

Home
About the Journal
Scope
Editorial Board
Submission Guidelines
Call for Papers

 

For information on the European Conference on Knowledge Management, click here

For information on the International Conference on Intellectual Capital, Knowledge Management and Organisational Learning, click here

Downloadable documents on this site require Adobe Acrobat Reader (free download here)

Sharing Contextual Knowledge in Today’s Workplace Environments (pp 1-12)
Farhad Daneshgar, University of New South Wales, Australia, and Chandra S. Amaravadi, Western Illinois University, USA
f.daneshgar@unsw.edu.au
Chandra_amaravadi@ccmail.wiu.edu

   

1.     Background

1.1     Introduction

The term Extended Office System (EOS) has originally been described as a system that allows users to make enquiries about concepts in the domain (Cordingley 1987). Based on this idea, the architecture of a system called AEI-3 that manages administrative knowledge has been introduced by Amaravadi (1998).  Administrative knowledge is the knowledge needed to perform the support operations in an organization and can include such things as the date a contract will expire or a customer’s idiosyncratic preference to be billed in instalments.  The acronym EOS also emphasises the fact that this variant of Knowledge Management system is the result of an outgrowth of existing office technologies (Ibid).  The main motivation for development of the AEI-3 was that as office systems become more sophisticated, it will be necessary to enhance their capabilities with knowledge management features.  Thus a Word processing system could be equipped with the capability to answer questions about budgets, clients and schedules. EIS-3 was a starting project for arriving at the above results.

One of the objectives of this article is to introduce an enhanced version of the AEI-3 that provides support to its collaborating users. In that sense, CAEOS is a collaboration-support version of the AEI-3. A summary of the two systems is provided in Table 1.

Due to its collaborative nature CAEOS must also maintain additional contextual knowledge regarding the collaboration among the office workers called in this article as the collaboration/contextual knowledge, or awareness. For example, knowing who is doing what; how and for whom they do it? Etc. Such awareness knowledge is represented in the proposed framework by a set of collaborative semantic concept including the roles of persons, the tasks that these roles perform (both in isolation as well as in collaboration with others), and the artefacts/resources/knowledge that are used by roles in order to perform those tasks. 

Moreover, in defining the operational and administrative knowledge, AEI-3 adopts the assumption that the nature of such knowledge is limited to explicit task-specific knowledge only. Such limited non-collaborative view is expanded under CAEOS and incorporates both knowledge of domain (as before) as well as the additional awareness knowledge of context including knowledge of roles, tasks, and artefacts, as defined in the previous paragraph. 

A thorough discussion about the proposed framework and its components is presented in Section 2. Section 3 is allocated to the objectives and characteristics of the CAEOS. In Section 4 the Network Management Case Study is presented. This will lead to Section 5 where conclusion and future work are presented.

Table 1: Main Features of the AEI-3 and CAEOS

 

Existing Version (AEI-3)

Proposed Version (CAEOS)

Main Function

To facilitate sharing of operational and administrative knowledge among those who need it.

To facilitate sharing of operational and administrative knowledge among collaborating office workers (see Section 1.3).

Method of accumulating knowledge

Knowledge repository consists of a linked set of structures linking the key concepts in the domain and descriptive assertions about them.

Knowledge repository consists of a linked set of structures linking the roles, tasks and artefacts (see Sections 1.2 & 2).

Process Model Representation

Intuitive; no formal framework used.

A formalised awareness framework is used (see Sections 1.2 & 2).

Participants are:

Both producers and consumers of knowledge (hence dual roles)

Potentially, all the collaborating office workers (hence uniform roles).

The Scope

restricted to the explicit administrative/operational knowledge only.

restricted to the knowledge (explicit/implicit) that exists in the pre-defined/non-emerging business processes (see Section 1.3).

Administrative Knowledge

Contents only (routine, diverse, fragmented, dynamic and explicit).

Both content and context (see Section 2).

 

1.2     Awareness provisioning methods for collaborative business processes

In daily dialog the word awareness is generally defined as “being conscious + in possession of information + cognisant + informed”. The word information on the other hand is defined as “knowledge or facts acquired or derived as from study, instruction, or observation + act of informing + being informed” (Halsey 1986).

With few exceptions, awareness has been regarded by researchers in the field of CSCW (Computer-Supported Cooperative Work) as a kind of information that is made available to (or targets) certain people for a specific purpose. For example, in co-located work, peripheral awareness is an awareness that is gained by implicit monitoring of the local work environment (Robinson 1993). Two examples are (Suchman 1986) and (Heath et al 1996) who describe the way in which workers will immediately re-orient their activities to support a critical situation simply on the basis of overhearing a phone call or noticing a change in another's voice tone.

Bentley et al (1992) on the other hand note the importance of a standardised display of the airspace to support air traffic controllers gaining at-a-glance awareness of the airspace others are controlling.

Media spaces are promoted as supporting informal shared awareness across distributed offices (Gaver et al 1995). Also, significant work is being undertaken in the CSCW community looking at ways of defining different types of awareness and supporting awareness (Fitzpatrick et al 1998). Most of these studies represent awareness as identified in ethnographic studies.

In majority of the above studies, the primary meaning of awareness implies that an individual becomes aware by perception of a given information about an object, and not by just receiving that information. This is the way the interactionists in the field of social psychology approach awareness. The writers of this chapter have extended the interactionists' approach to awareness to include office workers when involved in today’s collaborative office activities. According to this approach, awareness between objects in a given medium is manipulated via focus and nimbus, which are subspaces within which an object chooses to direct either its presence or its attention (Benford et al, 1993). The more an object is within your focus, the more aware you are of it; and the more an object is within your nimbus, the more aware it is of you. As a result of this definition, awareness levels can be derived from a combination of nimbus and focus: "The level of awareness that object A has of object B in medium M is some function of A's focus in M in relation to B's nimbus in M" (Ibid).

In order to operationalise the above concept of awareness levels within the context of collaborative business processes, an existing awareness framework (Daneshgar 2004) is extended here that maintains awareness levels of office workers at appropriate levels while performing various office works as explained in 4.2. 

1.3     Structured collaborative business process vs Administrative knowledge

The structured business process is defined in this article as a collection of a set of collaborative semantic concepts, that is, roles, tasks and artefacts, as well as the relationships among these concepts. Moreover, these concepts and relationships among them must either be stable over time (that is, must be defined beforehand), or must be defined at any given time with no uncertainty. The above implies that it will be problematic to use a pre-defined business process model if the actual process would need to deal with emerging/unexpected tasks. The reason is that the presence of an emerging task may require unplanned resources, resulting in contradictory and inconsistent outcomes and possibly a process failure. As a result, systems designed for task support under a predefined process discipline will allocate little resources if any (in the form of intelligence, algorithmic procedures, internal memory, etc.) for dealing with emerging tasks. In reality, however these systems let the human users of the system deal with such emerging situations. In our view, a majority of the administrative tasks are repetitive by nature, and can easily fall into the category of predefined tasks in the sense that both the steps of execution, task outcomes, roles, and artefacts can be predefined to a great extent. 

The proposed process model is primarily based on pre-defined knowledge about known relationships among roles, the tasks that these roles perform, and the artefacts that they use in order to perform their tasks. Such relationships seem to be quite relevant, applicable, and consistent with the context of the day-to-day and routine administrative and operational processes characteristic of the office life.

1.4     Need for a formalised process model

Traditionally, two groups of techniques have been used for representation of process models. These are graphical techniques and the declarative techniques (Amaravadi , 2001). Graphic specifications are usually variations of Petri-Nets, Data Flow Diagrams, State Transition Networks or Activity Networks (Amaravadi et al 1992). Semantic nets have been widely used for knowledge representation particularly in connection with natural language processing.  

In order to avoid limitations associated with the semantic nets we make use of Graph Theory in this article. A collaborative business process model is introduced that has roots in the Applied Mathematics. Compared with the semantic nets, the Graph Theory  allows use of already existing mathematical-oriented constructs for producing more sophisticated search/browse algorithms. This is partly demonstrated in Section 4 when identifying the awareness requirements of the roles by walking through the ‘process graph’ and expressing the results using the notations of Set Theory.   

2.     An awareness-based framework for representation of the Collaboration Aware Extended Office System (CAEOS)

Our proposed framework consists of the two components: a process graph, and an awareness model. These components are discussed in this Section.

2.1     The process graph:

Figure 1 shows one such representation using a connected graph. It shows a predefined collaborative business process that consists of a set of collaborative semantic concepts that are related to one another in a pre-specified manner. In this Figure, the roles  X, Y, T and V are shown by filled circles and each perform one or more tasks. Tasks are shown by normal circles. A role typically uses either tacit or explicit know-how in order to perform a simple task (as opposed to the collaborative task). This will allow different actors who play the same role for performing the same simple task (perhaps because they are different shift workers) to use their own tacit knowledge that may differ from others when performing the same task.

Figure 1: Examples of a Process Graph with four roles and 14 tasks

Performing a simple task means executing those steps of the tasks that do not compete with the steps of other tasks in terms of utilisation of the available limited resources/artefacts; hence the name ‘simple’ (Daneshgar 2000). On the other hand, if a role is to perform a collaborative task in conjunction with one or more other roles within the process, then the pair of simple tasks that constitute a collaborative task will have certain steps within them that will compete with (and must share) the available resources/artefacts. Ideally, such knowledge must be publicly accessible (and therefore, explicit) before the task can be executed successfully. Collaboration between a pair of roles means that they use some kind of explicit knowledge in order to perform certain steps that exist within the pair of simple tasks that together make up a single collaborative task. In this paper, the business process is shown by a Process Graph that shows collaborative semantic concepts (roles, tasks, and artefacts) and their relationships.

Another commonly practiced method of demonstrating a business process is to use workflow languages (Hawryszkiewycz 1997). However due to the limitations that these tools impose on the sequence of task executions they are not used in this article.

In the following paragraphs collaborative semantic concepts used in this article are defined:

Role: a set of norms expressed in terms of obligations, privileges, and rights. On the Process Graph of Figure 1 roles are shown by filled circles X, Y, T and V.

Role Artefacts: This object carries know-how of a simple task. Role artefacts can be either tacit or explicit. That is, they can be either within the mind of the actor who performs the role (eg, skills, experience, etc.) or they can exists externally but in private locations (eg, personal databases, spreadsheets, etc.). On the Process Graph, the role artefacts are shown by thick lines.

Simple and Collaborative Tasks: Simple Tasks are objects with a set of attributes and actions/steps to achieve a specific goal. On the Process Graph simple tasks are shown by twelve circles labelled ‘1’ to ‘8’ and ‘a’ to ‘f’. A collaborative task on the other hand is composed of two simple tasks that have a common goal; and as a result, they have certain actions/steps in common. These common actions/steps compete with one another in using available resources allocated by the CBP for execution of the tasks, and therefore must be shared effectively through the common task artefact discussed below.

Task Artefact: An object that carries knowledge about how various actions/steps associated with a collaborative task are executed. Contrary to the role artefacts where they may or may not exist within organised knowledge bases, it is assumed here that task artefacts are ideally kept within the organisational knowledge bases so that they can be accessed and used by multiple actors when they enact various roles for performing their collaborative tasks. On the Process Graph task artefacts are shown by thin lines linking two tasks together. 

2.2     An awareness model for the office workers

Following is a summary of some of the main characteristics of today’s office work from the perspective of the researchers in the field of CSCW (Computer-Supported Cooperative Work) who are frontrunner designers of today’s networked-oriented business models (Hawryszkiewycz 1997).

1.    Office workers may work at different times and at different places and yet, they all belong to the same business process and must collaborate through sharing documents, artefacts, resources, workstations, etc.

2.    Office work can range from being fully structured and predefined, to fully unstructured and emergent.

3.    Office work can range from fully personal to fully collaborative.

4.    Instead of repetitive simple tasks, an office worker may now have a portfolio of tasks and select the task that need most attention.

One universal requirement of all the above types of office tasks is that actors who perform tasks need to have certain level of contextual knowledge in the form of process awareness that is referred to in this article as process awareness. This is a level that is expected from office workers in order to perform their collaborative task successfully. Below a summary of five such awareness levels are introduced. For more details refer to (Daneshgar 2004).

Level-0 awareness: A role is at level-0 awareness if it possesses knowledge about the objects that lead the role to an understanding of the tasks that the corresponding actor performs within the process. As an example, level-0 awareness for a casual university lecturer may include the following ‘task’ and ‘role artefact’ objects:

§       Task 1: ‘delivering lectures for the subject’

§       Role artefact 1: ‘resources/artefacts required for such delivery’

§       Task 2: ‘preparing tutorial and exam questions’

§       Role artefact 2: ‘textbook and other references, etc.’

§       Task 3: ‘marking exam papers’

§       Role artefact 3: ‘exam papers, answers to the exam questions, etc.’

A role’s level-0 awareness will enable the corresponding actor to initiate lowest level of knowledge sharing transactions with other roles within the process (in this case nil, as the role knows nobody else within the process yet). In the Process Graph of Figure 1 level-0 awareness for ‘X’ is a set of paths that include the role vertex ‘X’, the tasks vertices ‘1’, ‘2’, ‘3’ and ‘4’, and the arcs that link ‘X’ to these tasks. In this article notation from Set Theory is used to demonstrate various levels/path of awareness within a business process. Level-0 awareness for the role X is:

A0('X') = {{X}, {X, 1}, {1}, {X, 2}, {2}, {X, 3}, {3}, {X, 4}, {4}}

Level-1 Awareness: This is the role’s level-0 awareness plus a knowledge about all objects that lead the role to an awareness/understanding of some of the other roles within the process. The ‘some of the roles’ here means those with whom the role has a direct task dependency. In Figure 1 role ‘V’ happens to have task dependency with one other role, that is, role ‘X’. Level-1 awareness allows ‘V’ to initiate a limited level of knowledge-sharing transactions with others (here, ‘X’ only). The mathematical representation of level-1 awareness for the role V is:

A1(‘V’) = {A0{V}, {d, 1}, {1}, {1, X}, {X}}

Or, alternatively,

A1(‘V’) = {A0(V), {d, 2}, {2}, {2,X}, {X}}

Level-2 Awareness: A role’s level-2 awareness is his/her level-1 awareness plus knowledge about objects that lead the role to an understanding of all other roles within the process whether the role has task dependency with them or not. According to Figure 1, the mathematical representation of level-2 awareness for the role X is:

A2('X') = {A1 ('X'), {4, 6}, {6}, {6, b}, b, {b, V}, {V}}

Notice that from its level-1 awareness the role ‘X’ already knows ‘Y’ and ‘T’. The only remaining role to be known to him/her is ‘V’.

Level-3 Awareness: A role’s level-3 awareness is his/her level-2 awareness plus knowledge about the objects that lead the role to an understanding of all the interactions (that is, all the task artefacts) that occur between any pair of roles within the process. In Figure 1, the mathematical representation of the role Y’s level-3 awareness  is either:

A3(‘Y’) = {A2(Y), {5, 4}, {4}, {4, X}, {X, 1}, {1}, {1, d}}

or,

A3(‘Y’) = {A2(Y), {6, 4}, {4}, {4, X}, {X, 2}, {2}, {2, d}}

Depending on the chosen alternative path at the level-1.

Level-4 Awareness: A role with level-4 awareness will possess the highest level of process awareness. It is the knowledge of objects that lead that role to an understanding of how all the objects within the process (that is, all the roles, tasks, role artefacts and task artefacts) fit together to make the process graph. Graphically, the process graph in its entirety can represent this level of awareness.

3.     Objectives of the CAEOS

In this article the term Collaboration-Aware Extended Office System (CAEOS) refers to an extended version of the IEA-3 that maintains awareness requirements of its collaborating users. As a result of the CAEOS’ capability of enhancing collaboration of the office workers, the following two objectives are added to the previous objectives of the IEA-3 extended office system:

The first objective is to enhance collaboration among the office worker. The two components of the proposed framework, that is, the process graph and the awareness model, are the main analytical tools used for both representation of the collaborative business process, as well as for identification of the awareness requirements of the collaborating actors within the process and were discussed in previous Section. 

The second additional objective of the CAEOS is related to the nature of the task artefacts. It is only natural to expect CAEOS to facilitate creation, acquisition, capture, access and reuse of the task artefacts. One may claim that management of these artefacts corresponds to the document centred strategy for knowledge management, whereas management of the actors and tasks correspond to the community-based strategy of the knowledge management. See Hansen et al (1999) for a thorough discussion on these two approaches. As mentioned before, task artefacts are public artefacts that are shared by various office workers in order to perform their collaborative tasks. For this reason, task artefacts must ideally be always accessible and sharable by relevant collaborators. In other words, knowledge within a task artefact must ideally be codified and stored in an integrated manner in a way that office knowledge can be shared on demand. By this CAEOS is playing the role of knowledge facilitator that brings knowledge source and knowledge user together in a variety of modes. This is so because while it has the capacity to separates knowledge from its sources, due to the integrated nature of the process map, it is also capable of tracing the knowledge back to its origin and to further keep track of its originator’s context (that is, for performing which task) did the originator issued/created/modified certain task artefact.

The role artefacts on the other hand are more personal. They either reside in people’s minds or, in certain situations they may reside in personal databases or private workstations. A third objective for CAEOS would therefore be to assist office workers in creation, organization and utilization of process awareness knowledge that is needed to perform tasks. This we call the ‘knowledge utilization role of the CAEOS’.      

4.     An example of applying the awareness framework to the office business processes: A network management case study

4.1     Background

In the previous discussion it was mentioned that awareness-provisioning is one of the main objectives of the CAEOS.This Case Study demonstrates application of the proposed awareness framework in a typical office environment, and that how the framework can be used to enhance collaboration in this office process. 

Several interviews were conducted with the actors involved in the process in order to derive the Process Graph for this collaborative process, as shown in Figure 2. In this Figure, roles are shown with filled circles and tasks are shown with normal circles. The actual and required levels of awareness for various roles is shown in Table 2. Columns of this Table were derived from the interviews made with various actors as well as additional task and problem domain analyses performed by an actor with level-4 awareness.

Table 2: Association between the actors' satisfaction level and the awareness gap

Inter-action #

 

Co   1

Pair of roles

involved in this

interaction

Col. 2

Required Level for the roles

Col. 3

Actual Level of each role

Col. 4

Aware-ness Gap

 

Col. 5

Satisfaction

Level

 

Col. 6

 

1

Technician-

Test Controller

1-1

1-1

No

8(High)

 

2

Technician-

Change Manager

3-2

1-2

Yes

3(Low)

 

3

Change Manager-

User

4-1

3-0

Yes

3(Low)

 

4

User -

Operator

3-3

1-0

Yes

3(Low)

 

5

User-

Change Manager

3-4

1-3

Yes

3(Low)

 

6

Technician-

Operator

2-3

1-1

Yes

2(Low)

 

 

Column 1 of the Table 2 shows various interactions within the process, and are numbered 1 to 6. These interactions always involve a collaborative task (or, a pair of related simple tasks) related to a pair of roles. 

Column 2 of the Table 2 shows the pair of actors involved in each of the 6 interactions. Columns 3 and 4 show the required and actual levels of awareness respectively for each actor and for each task separately. It must be mentioned here that the actual level of awareness is the level that an actor of a role actually posses and is an attribute of the role; whereas the required level of awareness is the level that is attached to a particular task (an attribute of the task object) and is the level of awareness that is expected from the actor/role who performs that particular task. The existence of awareness gap for each interaction is indicated in column 5 of this Table. Awareness gap for a role is the excess of the required level of awareness of the task that the role plays over the actual level of awareness that the role already possesses. For example, in interaction 3, actual level of awareness 3-0 means the actual level of awareness of the Change Manager is 3 whereas that of the User is 0. In the same transaction, the required level of awareness 4-1 means that Change manager requires level-4 awareness for the task Impact Control whereas the User requires level-1 awareness for the task Impact Analysis. This indicates that there is a definite awareness gap in this interaction, hence the entry "yes" in column 5. For similar token, no awareness gap exists for the interaction 1.

 

Figure 2: Process Graph for the Network Management Case Study

The actors' satisfaction levels corresponding to each interaction were also recorded in column 6 of the Table 2. The method used to arrive at the satisfaction levels in column 6 is as follows:

Each interaction in column 1 involves a pair of actors. These actors were interviewed. Since some actors participate in more than one interaction, more than one interview was held for these actors. A total of twelve interviews were conducted with the actors participating in the 6 interactions. All the actors, with the exception of the “User”, are called by the ‘role’ that they play (eg., “Technician”, “Test Coordinator”, “Change Manager”, and “Operator”). In the case of the “User” where up to five actors plays this role, the actors are referred to as “User1” to “User5”.

The purpose of the interview was to obtain qualitative information about the details of each interaction/scenario. Such qualitative information was then used to provide the actor in one side of the interaction an opportunity to rank their satisfaction of the services provided by the actor on the other side of the interaction, and vice-versa. More specifically, lists of the problems that the actors have been facing in each interaction were collected, summarised, and structured. For each interaction a ‘Satisfaction Ranking Scheme’ for that particular interaction was used by the actors to decide on a satisfaction rank between 0 to 10 for the services that were provided by the actors on the other side of the interaction. To avoid repetitive details results of the application of the “Satisfaction Ranking Scheme” to the interaction 3 are reported below:

Interaction 3: Change Manager explains to, or notifies the, affected Users of a possible need for network shutdown.

Problems that led to low level of the actors’ satisfaction (that is, five Users’ and the Change Manager) are:

§         There is no automatic change impact notification. All concerned need to be informed manually and hence the chance of omissions. Four out of five “Users” have expressed such nonsatisfactory experience at least once in the past. The average rank for the “Satisfaction Level” given by the five Users to this interaction act was 2.8. Each User’s rank carried a statistical weight of one. Change Manager was not allowed to provide a rank for the “Satisfaction Level” for this item since he was considered to be the provider of this service.

§         “Change Manager” reported another problem: Some Users do not respond at the time of notification. Currently, there is no means for the Change Manager to chase the Users. A “Satisfaction Rank” of 3 was given to this interaction by the Change Manager. This rank carried a statistical weight of five so that the actors in both sides of the interaction carry the same weight when deciding on the “Satisfaction Level” for that interaction. Users were not allowed to provide any rank for this interaction act.

§         Quite often, both Users and Change Manager cannot be located (no mobile computing facilities were available for mobile actors). Both the “Users” (each with weight 1) and “Change Manager” (with weight 5) provided ranks for this interaction. The overall average was 2.8. The average value rounded to the nearest whole number for this and other interactions are shown in Column 6.

Results in columns 5 and 6 indicate negative association between the actors' satisfaction (represented by high values of satisfaction level) and the awareness gap between actual and required levels of awareness of the actors involved in each interaction.

4.2     Statistical test of significance of the correlation between the customer satisfaction and the awareness gap

In order to prove the existence of a strong negative correlation between the awareness gap and the actor's satisfaction with significant level of confidence, the differences between the actual and required levels of awareness are calculated for each interaction and then correlated with the satisfaction level. Following results were obtained:

                        Coefficient of Correlation, r = - 0.732

            SE(r) = 0.41

            r/SE(r) = - 1.04/0.41 = - 1.78

The above value can be accepted at a 2% confidence level. We can therefore conclude with 98% certainty that there is a negative correlation between the level of satisfaction of the actors and the awareness gaps.

4.3     Further analysis: Identifying improvement priorities

On the basis of the above findings, the designers of enterprise network management process can now work on the right type of collaboration support for various interactions within the process. Similar results were obtained in a number of scenarios studied at this organization. Further investigations revealed the following reasons for the existence of the awareness gaps in the above interactions. These in turn, can be translated into various functions of the CAEOS:

1.    Since there is no automatic change impact notification, all concerned need to be informed manually, and hence, there is a chance of omission. There is a need for the system to automatically create a notification list based on the network topology (what we refer to in this paper as focus) so that required level of awareness are maintained on a timely basis (referred to as nimbus).

2.    Although all users are notified, some users do not respond at the right time. Therefore it is necessary to include the impact information in the interaction to the user so that in the case of some users not responding, it may be necessary to chase them up; hence the need for a "to do list" for every change, as a minimum. Ideally, an integrated coordination subsystem within the CAEOS would be ideal. Another alternative would be to assign a software agent with at least level-3 awareness, to monitor every interaction, and ensure a quick reply for some of the time-sensitive types of notifications.

3.    System workflow should take care of interlocks. This will require agents to (automatically) remind users of some information either periodically or after certain number of transactions.

4.    Often, Users and Technician cannot be located, meaning that either level-1 awareness does not effectively exist for those who try to access these actors, or, perhaps such level-1 awareness is out of date. Hence, there is a need for mobile communication solution so that level-1 awareness can be maintained for all actors who want to access Users and Technician at all times.

5.     Conclusion and future work

In today’s networked economy office environments need effective support for collaboration among office workers at anytime and anywhere. This article demonstrated that the existing EOSs are not specifically designed to maintain contextual/awareness knowledge requirements of the collaborating actors of today’s collaborative office processes. An awareness framework was applied to a network management case study and effectiveness of the framework in identifying the awareness requirements of the actors within the collaborative process was assessed with positive results. The framework was then used as a conceptual tool to derive general design directives for a Collaboration-Aware EOS (CAEOS) system that facilitates sharing of the contextual knowledge among office workers. It is suggested that the above awareness framework be automated within the CAEOS as an inference subsystem in order to facilitates identification of the actors’ awareness requirements, as well as their awareness gaps, if any.

More specifically, CAEOS ideally consists of a pair of inter-related components: (i) a knowledge-base that defines, represents and stores the domain knowledge in terms of the collaborative semantic concepts provided, as well as their relationships. It also consists of methods/rules of calculating various awareness levels using the domain knowledge. The other component, the inference engine/model provides foundation for inferencing the awareness gaps for each actor.

Some possible functions of the CAEOS are:

1.    Dynamically constructing the office process maps as a reference points for those involved in these collaborative processes.

2.    Measuring the actual levels of awareness of the office workers before performing certain tasks, and identification of their awareness gaps.

3.    Automation of the flow of the office tasks based on the awareness levels of the workers. This can also be a partial solution to management of the task flows in emerging processes in situations where unexpected actors may have to take up the task.

4.    CAEOS can also be used as a project management tool for allocating various tasks to the office workers on various processes/projects, on the basis of their relative actual level of awareness of each business process/project.

And as a final point, as the number of roles and tasks increases, the traditional database technology will be ineffective in creation, organization and utilization of awareness knowledge; more advanced techniques need to be investigated for these situations. Integration with other Extended Office Systems will also remain an important issue that needs be addressed in future studies.

References

  • Amaravadi C., Sheng O.R., George J.F. and Nunamaker J.F. (1992): ‘AEI:A Knowledge-based to integrated office systems’, Journal of Management Information Systems, vol. 9:1, pp.133-163.

  • Amaravadi, C (1998):’Research Issues in Office 0Information Systems’ in Proceedings of  IFIP- Working Group 8.4.

  • Benford S. and Fahlen L.E. (1993): ‘A Spatial Model of Interaction in Large Virtual Environments’, Proceedings of the 3rd-ECSCW, Milano, Italy.

  • Bentley R., Hughes J.A., Randall D., Rodden T., Sawyer P., Shapiro D., and Sommerville I. (1992): ‘Ethnographically-informed Systems Design for Air Control’, in Proceedings of Conference on Computer-Supported Cooperative Work, Toronto, Canada, pp.123-129.

  • Cordingley, E (1987): ‘Intermediate Knowledge Representation for Extended Office Systems1, Proceedings of IFIP, pp. 61-69.   

  • Daneshgar F. (2004): ‘Awareness Net: An Integrated Modelling Language for Knowledge Sharing Requirements in Collabortive Process’, Journal of Conceptual Modelling, Issue 32, May 2004.

  • Daneshgar F. (2000): An Awareness Framework For Business Processes, PhD Thesis, School of Computer Science, University of Technology Sydney, Australia.

  • Fitzpatrick G., Parsowith S., Segall B., and Kaplan S. (1998): ‘Tickertape: Awareness in a single line’, Proceedings of CHI98, ACM Press, Los Angeles, pp.281-282.

  • Gaver W., Smets G. and Overbeeke K. (1995): ‘A Virtual Window on Media Space’, Proceedings of CHI'95, Denver, Colorado, pp.257-264.

  • Halsey, W. D (1986): Macmillan Dictionary, Macmillan Educational Company, New York.

  • Hansen, M. T., Nohria, N., & Tierney, T. (1999). ‘What’s Your Strategy for Managing Knowledge?’, Harvard Business Review, 77(2).

  • Hawryszkiewycz I. (1997): Designing Network Enterprises, Artech House, Boston, USA, pp.35-100.

  • Heath, C and Luff, P (1996): ‘Convergent Activities: Line Control and Passenger Information on the London Underground’, in Cognition and Communication at Work, Yrjo Engestrom and D Middleton (editors), Chapter 5, Cambridge University Press, Cambridge, pp. 96-129.

  • Robinson, M (1993): ‘Design for Unanticipated Use’ in Proceedings of the 3rd European Conference on Computer-Supported Cooperative Work, Milan, Italy, pp.187-202.

  • Suchman, L (1986): ‘Constituting Shared Workspaces’, chapter in Cognition and Communication at Work, Yrjo Engestrom and D Middleton (editors), chapter 13, Cambridge University Press, Cambridge, pp.35-60.
 
Copyright   © , 2004  

Home Up Papers in Current Issue Previous Issues Site Map

EJKM is published by Academic Conferences International Limited
Curtis Farm, Kidmore End, Nr Reading RG4 9AY, England
Tel: +44 (0)1189 724148, Fax: +44 (0)1189 724691, Email: info@ejkm.com

Send mail to info@academic-conferences.org with questions or comments about this web site.
Copyright © 2003-2006 Electronic Journal of Knowledge Management
Last modified: January 25, 2006
ISSN 1479-4411