Context Management of ERP Processes in Virtual Communities

Farhad Daneshgar

University of New South Wales, Australia

Copyright © 2003, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

Abstract

A methodology is proposed for sharing the contextual knowledge/resources that flow within ERP processes in virtual communities. Context is represented by a set of relevant collaborative semantic concepts or "objects." These are the objects that are localised/contextualised to specific sub-process within the ERP process. Two sets of objects are identified: (i) objects that make up a community member's actual contextual knowledge/resources with regards to the ERP process, and (ii) objects that make up the required contextual knowledge that various sub-processes/tasks expect from the member to possess for successful execution of those tasks. The excess of the objects in (ii) compared to those in (i) are identified and are put within the focus of the community member in order to enable the member to effectively participate in various collaborative interactions within the community's ERP process(es).

Introduction

The main motivation for this chapter is to introduce a specialised version of an existing awareness-based ERP methodology (Daneshgar, 2001) for Virtual Communities, or VCs for short. To this end, the primitives, focus and nimbus, that seem to have relevance to the VCs are explicitly incorporated into this existing ERP methodology.

According to the interactionist school in social psychology, awareness is maintained if each person actively provides a kind of nimbus by which s/he selectively exposes some of his/her properties (that is, their activities, etc.) to the others. According to this school, pairwise interactions between people occur either by nimbus (an object's presence), or by focus (its attention); the more an object is within one's focus, the more aware the person is of it. Also, the more an object provides a nimbus, the more aware others will be of it (Benford et al, 1995).

In this chapter the writer, being primarily member of both the CSCW (Computer Supported Cooperative Work) and the Knowledge Management research communities, introduces a conceptual framework for ERP processes in virtual communities which possesses the following attributes:

• As before, this extended framework emphasises the collaborative nature of the ERP process, in the sense that awareness and knowledge-sharing issues within the ERP process are explicitly addressed
• In addition, it identifies collaboration requirements of the actors within VCs, with VCs being regarded as a sub-class of the business community in which members work flexibly anywhere and at anytime. The collaboration requirements of the actors within the community are defined in terms of resources and knowledge that the actors require in order to perform their tasks within the community.
• And finally, the proposed framework is affected by the latest trend that is currently occurring within the field of Knowledge Management. According to this trend, we are reaching the end of the second generation of Knowledge Management/sharing, with its focus on tacit-explicit knowledge conversion as triggered by the SECI model of Nonaka (Nonaka, 1991). The third generation requires the clear separation of context, narrative and content management and challenges the orthodoxy of scientific management (Snowden, 2002). It is argued in this chapter that people in VCs require certain level of contextual knowledge about various resources/knowledge related to the collaborative nature of the ERP process, such as Who?, Doing what?, Using what resources? What skills?, etc. This type of contextual knowledge is now being distinguished from the actual content of the knowledge/resource itself. Such contextual knowledge is a pre-requisite to the VC members' effective involvement in various interactions within the ERP processes. In other words, and as far as the writer is aware, the methodology presented in this chapter is the first in its kind that ultimately fits into the context management/sharing category of the context- narrative-content taxonomy in the field of Knowledge Management as briefly mentioned before.

More specifically, the contextual knowledge is represented here by a set of relevant objects that have been localised/contextualised to actors within the ERP process in VCs. These objects make up channels within which the actual collaborative resources or contents (of knowledge and/or physical resources) within the ERP process flow; hence the term contextual knowledge.

Two sets of objects are identified: (i) objects that make up a community member's actual contextual resources/knowledge and are actually possessed by the community members, and (ii) objects that make up various required contextual resources/knowledge that are imposed by the (nature of the) tasks that these members perform within the community and, therefore, are expected from them as they perform the task. Within the (relative) context of an actor performing an ERP-related task in the VC, the excess of the objects in (ii) over those in (i) are identified by the framework. As the next step for enhancing collaboration and resource/knowledge sharing within the ERP process, these excessive objects are either explicitly put within the focus/access of the actor, or these objects themselves evaporate a kind of odour/nimbus in order to attract attention of the actor, or a combination of both.

Like many existing ERP frameworks/models, the proposed framework is also based on a widely accepted assumption that a corporate-wide information system consists of a set of potentially related subsystems. As a result, channels within which the contextual collaborative resources/knowledge flow among these subsystems must be identified, and required resources be planned. The proposed methodology treats an ERP process as a collaborative process, and, as a result, a set of collaborative semantic concepts are used for representation of the ERP process. This process representation consists of multiple interrelated subprocesses, with each subprocess in turn being composed of one or more simple tasks (as opposed to the collaborative tasks explained later), or tasks for short. Each task requires certain resources (including knowledge) for achieving its local goal or purpose, as well as certain other resources/knowledge for achieving its collaborative goals with others within the ERP process. The term task resource is used to describe resources (including knowledge) required for performing a task with no regard to the task's collaborative resource requirements. On the other hand collaborative resource is used to describe additional resources required by a task in order to collaborate with others through their tasks.

Each task is performed by a role and each role is played by a human agent, called actor, although there is no representation for the actor in the proposed framework, and the actor is indirectly identified by the role that they play at any time within the ERP process. When an actor performs a task collaboratively with another actor, then we call the task a collaborative task that consists of a pair of (simple) tasks, each played by a different role; hence a need for additional set of (collaborative) resources in order for the collaboration to be realised.

Another unique characteristic of the proposed framework is that it regards effective communication or information/resource exchange among the actors as being closely related to the level of awareness an actor has. An actor's awareness level is closely related to his/her extent of contextual knowledge with regards to various aspects of the ERP process and, as mentioned before, is distinct from the actual content. Examples include who (the role) is doing what (the task), how, using what resources, what skills, etc. Have a look at this familiar scenario:

"... If our systems had been communicating, the instant the record closed out in our system the sales guys would have known it ... There are three forecasts for monthly sales and I couldn't reconcile them. Accounting uses some kind of dollarized forecast for cash planning purposes. The sales guys are using their Ouija boards and other sorcery to figure out what deals they will close ... entering the data, especially since it is done only once, requires extensive formal procedures" (Jacobs & Whybark, 2000, pp. 12–13).

A Process Awareness Methodology for ERP in VCS

This section introduces a methodology for identifying awareness requirements of actors in an ERP process within VCs. Such requirements can then be used to plan various resources within the enterprise. The steps for this methodology follow:

Step 1

Develop a conceptual representation model for the ERP process using a set of collaborative semantic concepts. This model shows all the activities within the ERP process in the form of various tasks that are performed by actors, by assuming certain roles using two categories of resources: task resources and collaborative resources. This conceptual model is called ERP Process Map. Detailed description of the ERP Process Map is given in the following section.

Step 2

Measure the actual levels of awareness of each role that exists on the ERP Process Map using the Awareness Model. Actual level of awareness is a property of the actor; and the role simply inherits such awareness from the actor who plays it. Depending on its numeric value, this actual level of awareness may consist of a subset of collaborative semantic concepts or objects that make up the ERP Process Map. These collaborative semantic concepts are:

1. roles,
2. tasks,
3. task resources, and
4. collaborative resources.

As an example, we may identify the following subprocesses/subsystems in an ERP process:

• Financial Accounting (FA)
• Order Processing (OP)
• Customer Service (CS)
• Financial Reporting (FR)

We can say that FA subprocess consists of a set of tasks identified by FA_T1, FA_T2, FA_Tn; OP subprocess may consists of tasks OP_T1, OP_T2, etc. Role R1 may play FA_T1, FA_T2 and OP_T1, whereas role R2 may play FA_T4, FR_T1 and FR_T6. R1 needs task resource PR_R1_FA_T1 for performing FA_T1 task (shown by an arc connecting R1 to FA_T1), and R2 needs task resource PR_R2_FR_T1 for performing FR_T1 task (shown by the arc connecting R2 to FR_T1), etc. Let us assume that the two tasks, FA_T2 and FR_T1, are executed collaboratively and for this collaboration to occur a task resource TR_FA_T2_FR_T1 is required (shown by an arc connecting FA_T2 to FR_T1). A graphical representation of this ERP process is shown in Figure 1.

Figure 1: An example of an ERP Process Map with two roles, six simple tasks, and one collaborative task

To measure the actual level of awareness of an actor, s/he must be exposed to all the objects that exist on the ERP Process map and be asked to identify those objects that s/he is aware of. The selected pool of objects is then fed to the awareness model that is the second component of the proposed framework. A cardinal number will be arrived at that reflects the role's actual level of awareness. These levels are explained in the following section in more detail.

Step 3

The actor's actual level of awareness is then compared against the required level of awareness as specified by (or, being a property of) the task that a role may perform within the process. This required level of awareness is the minimum level of awareness that is expected from any role who intends to perform this task. The factors that may affect the value are organisational culture as well as nature of task itself. This value reflects the fact that without such minimum level of awareness the actor will not be able to perform the task properly. A comparison between the actual level of awareness of the actor and the required level of awareness of the task will result in one of the following two outcomes:

1. Either: the required level of awareness of the task is equal to, or less than, the actual level of awareness of the role. This indicates that the role is qualified, or has sufficient level of awareness for taking up the task as the awareness requirements of the task are satisfied.
2. Or: the required level of awareness of the task exceeds the actual level of awareness of the actor. This indicates that the role does not possess required awareness. In other words, the actor is not aware of a set of objects within the ERP Map and therefore the next step must be followed.

Step 4

In order to remove the above awareness gap in VCs, special attention needs to be given to the specific nature of VCs. In traditional business processes, the concept of 'nimbus' has not been given much attention in actual implementations of systems that support collaboration and sharing of artefacts and resources. In VCs, where people and work are distributed over the times/space taxonomy, issues related to nimbus, such as selectively desire to hide, and yet to participate effectively within the community, odour (selectively giving others access to personal knowledge/skills/resources), and any other factor that VC members selectively use to represent themselves to others, become quite relevant when dealing with the sharing of knowledge and resources. On the other hand, clear separation of content and context, as mentioned before, will have a particular implication in VCs. Contents of knowledge/resources are more absolute and fixed than the context/channels within which knowledge/resource flow and/or are shared. Both as a result of this, as well as due to the nature of the VCs, the same context can be seen by different people differently, depending on a combination of the degree of willingness of the object to expose itself (nimbus), as well as the eyesight of the viewer (focus). In other words, the awareness of actors in VCs depends on both his/her focus as well as the others' nimbus.

Following section further clarify details of Step 4 of the proposed methodology.

Components of the Framework

The proposed framework consists of the following two components:

1. a connected graph as a conceptual model for the ERP process (called ERP Process Map), and
2. a new model for process awareness in the form of a set of algorithmic procedures that can be used to parse the above graph in order to identify various objects that constitute various levels of awareness associated with various roles and tasks within the ERP process.

Process Map

ERP Process Map is a planning and analysis tool that models the ERP collaborative process using a limited number of collaborative semantic concepts (or objects) that are linked together through various resources (including the knowledge). These concepts are briefly discussed below. Readers are advised to refer to Daneshgar (2000) for full details.

Task (Also Called 'Simple Task')

Definition: Objects with a set of attributes and actions to achieve a specific process goal using certain resources.

Representation: It is uniquely identifiable by a combination of one or more of its attributes (e.g., required level of awareness, goal, ID number, description, etc.), as well as its actions. In Figure 1 simple tasks are graphically represented by vertices FAT_T1, FAT_T2, FAT_T4, FR_T1, FR_T6 and OP_T1.

Action

Definition: A sequence of goal-directed steps.

Representation: Actions are secondary concepts in the proposed frame-work and therefore there is no direct graphical representation for the "actions." They are embedded within the task objects.

Collaborative Task

Definition: is composed of two (or more) simple tasks that share the same collaborative resource and have a common goal.

Representation: Collaborative tasks are graphically represented by the associated simple tasks and the shared collaborative resource arc that links the tasks together. The only collaborative task in Figure 1 is the pair of FAT_T2 and FR_T1.

Actors

Definition: These are human agents that enact a set of simple tasks by playing a set of roles.

Representation: There is no direct graphical representation for these objects. Actors are embedded within the roles that they play within the ERP process.

Role

Definition: A set of norms expressed in terms of obligations, privileges, and rights.

Representation: Roles are graphically represented by vertices of the connected graph. In Figure 2, roles are shown by filled circles.

Task Resource

Definition: This object represents resources that a role utilises in order to perform a simple task in isolation from any other task(s).

Representation: Task resources are graphically represented by the arcs that connect a role vertex to a simple task vertex.

Collaborative Resource

Definition: These are resources used by the actors (at least a pair of actors) in order to perform certain simple task in collaboration with another actor(s) who perform a related simple task.

Representation: Collaborative resources are shown by the arcs that connect two related simple task vertices together.

ERP Process

Definition: A set of roles, task resources, simple tasks, and collaborative resources that are linked together in order to achieve certain ERP-related goal.

Representation: ERP Process is graphically represented by a connected graph similar to the one in Figure 1. An ERP Process is collaborative if at least one collaborative task exists in it. It seems that ERP Processes are always collaborative.

Awareness

Definition: Awareness is specialised knowledge about the objects that lead an actor to an understanding of various aspects of the ERP process. This specialised knowledge is defined in terms of various roles, simple tasks, collaborative tasks, task resources and collaborative resources.

Representation: Graphical representation of various levels of awareness of an actor includes a set of the objects (above collaborative semantic concepts) that constitute various paths from the actor's role vertices to each other vertices of the ERP Process MaP.

Actual Awareness

Actual Awareness is the awareness that an actor actually possesses within the ERP process. Actual awareness is represented by an integer number, ranging from zero to six, representing various levels of awareness.

Required Awareness

Required Awareness is an awareness that is attached to (and is an attribute of) each task and represents the expected level of awareness from the actor who performs the task. Its representation is the same as actual awareness.

The Awareness Model

It provides a new definition for process awareness for ERP processes in general, and for VCs in particular. The sharing of the contextual knowledge in VCs occurs at various levels depending on both focus and nimbus of the semantic concepts involved. Seven levels are identified in this chapter and are discussed below:

Level-0 Awareness

An actor is at level-0 if s/he possesses contextual knowledge about the objects that lead the actor to an understanding of the tasks that the actor performs within the VC. This knowledge is the sum of the actor's focus (his visibility and eyesight), as well as the tasks' nimbus (how clearly the tasks are presented to, and then conceived by, the actor). An example of level-0 awareness for an accountant includes: "I, the accountant (role) use a kind of dollarised forecast (role artefact) for cash planning purposes (task)." The role's accounting knowledge is his/her focus; whereas how clearly the task of "planning" is presented to the accountant (e.g., proper on-line help facilities, floor-control issues of the VC's chat rooms, etc.) is the nimbus that evaporates from the task object. An actor's level-0 awareness is sum of contextual knowledge about the objects that lead the actor to knowledge about all the simple tasks that the actor performs within the process.

Level-1 Awareness

Level-0 awareness is a prerequisite for level-1. An actor that reaches level-1 awareness will possess a specialised knowledge about all the objects that leads the actor to awareness about some of the actors within the VC. These are the actors with whom the actor has a direct task dependency.

Level-2 Awareness

An actor at level-2 awareness will have a knowledge about the objects that lead the actor to an understanding of every (other) role within the VC.

Level-3 Awareness

An actor at level-3 awareness has the knowledge about the objects that lead that actor to an understanding of all the interactions that occur between any pair of roles within the VC. Attaining level-3 awareness enables an actor to initiate level-3 context-sharing transactions with others within the VC.

Level-4 Awareness

An actor at level-4 awareness has a specialised knowledge about the objects that lead that actor to an understanding of how everything within the VC fit together to make up the ERP Process Map. Graphically, this level can be represented by the whole of the ERP Process Map. At this level, the actor has adequate contextual knowledge about what everyone does within the VC and how (using what resources, etc.) they perform their tasks (that is, the sum of everybody's level-0 awareness), who directly collaborates with whom and how (sum of all the level-1 awareness), who indirectly collaborates with whom and how (sum of all the level-2 awareness), and finally, how other actors collaborate with one another (sum of all the level-3 awareness).

Level-5 Awareness

Level-5 awareness is a knowledge about the objects that lead the actor to an understanding of the actual relationship between the ERP process and the overall context of the VC. At this stage, no graphical representation model exists for this level of awareness. This level represents the theoretical limit of the proposed framework, and its appearance in this chapter is simply due to its fitness to the overall evolutionary nature of the awareness. No further discussion will be given regarding this and the next level of awareness.

Level-6 Awareness

Level-6 awareness is a knowledge about the objects that lead the actor to an understanding of the history of the ERP process at different times as well as in similar communities at present time.

Implementation Issues of the Proposed Framework

On the basis of this framework, the writer is in the process of developing an expert system that provides expert advice for answering the following two main questions:

1. In terms of awareness requirements, is an actor capable of performing a certain task within the ERP process?
2. If not, what objects need to be put within his/her focus in order to enable the actor to perform the task properly?

In the example of Figure 1, the ERP process has four subprocesses (that is, Financial Accounting FA, Order Processing OP, Customer Service CS and Financial Reporting FR). The notion of a subprocess is encapsulated within the individual tasks and its relevant resources. Each task possesses a set of attributes and relevant actions/steps. These attributes will indicate to which subprocess the task belongs. This will enable an actor to play various roles within different subprocesses without being permanently linked to a specific subprocess, a factor that can remove some complexities in existing ERP implementations. The interdependency that exist between various subprocesses is also simplified by encapsulating them within the task objects and their related resources in such a way that each task has equal opportunity (or follows same standard) to be linked to any other task within the ERP process, including to those tasks within the same subprocess. This will also reduce much of complexities that may exist in process-oriented ERP systems where the system must permanently maintain such linkages.

Conclusion and Future Work

This chapter introduced a conceptual object-oriented framework based on process awareness for analysis and design of ERP systems for VCs, and its advantages over the process-oriented systems were also discussed. It was shown that knowledge space can be expanded by identifying the awareness gaps for various actors within the community. It was further suggested that these objects can either be put within the focus of the actors, or can be encouraged/ motivated to evaporate appropriate nimbus to automatically attract the attention of the actors who need to be aware of the object, or both. From a CSCW (Computer-Supported Cooperative Work) perspective these can be done by the means of effective interfaces that, among other things, encourage articulation work (Gerson, 1986), explicification of situated actions (Allen, 1984), identification of mutual influence (Robinson, 1991a), facilitation of shared views/ shared materials (Robinson, 1991b), and provision of a double-level language that allows both ambiguity and clarity (Robinson, 1991a). These fundamental concepts have been selected and are being investigated by the author from the CSCW literature as an initial effort for addressing the process of effective management of the contextual knowledge in ERP processes of VCs.

References

Allen, T. J. (1984). Managing the flow of technology. Cambridge: MIT Press.

Daneshgar, F. (2000). An awareness framework for business environments. PhD Thesis. School of Computer Science. University of Technology, Sydney (UTS), Australia.

Daneshgar, F. (2001). An object-oriented awareness-based methodology for ERP. In L. Hossain & J. Patrick (Eds.), Enterprise resource planning: Opportunities and challenge. Hershey, PA: Idea Group Publications.

Gerson, E., & Star, S. (1986). Analysing due process in the workplace. ACM Transactions on Office Information Systems, 4 (3).

Jacobs, F.R., & Whybark, D.C. (2000). Why ERP?: A primer on SAP implementation. New York: McGraw-Hill Higher Education.

Nonaka, I. (1991, November-December). The knowledge-creating company. Harvard Business Review, pp. 96–104.

Robinson, M. (1991a). Double level languages and cooperative working. AI & Society, 5, 34–60.

Robinson, M. (1991b). Computer supported cooperative work: Cases and concepts. Proceedings of Groupware 91, SERC. Utrecht, The Netherlands.

Snowden, D. (2002). Complex acts of knowledge: Paradox and descriptive selfawareness. Special Issue of the Journal of Knowledge Management, 6 (2).