An ontology-based competency model for workflow activity - CiteSeerX

An ontology-based competency model for workflow activity assignment policies A. Macris, E. Papadimitriou and G. Vassilacopoulos

Abstract

A. Macris (pictured) is based at the Department of Business Administration, University of Piraeus, Piraeus, Greece. E. Papadimitriou and G. Vassilacopoulos (pictured) are based at the Department of Informatics, University of Piraeus, Piraeus, Greece.

Purpose – Assigning business process activities to agents (human or automated) for their performance or supervision is a critical issue in business process management. Role-based approaches are commonly used to specify work assignment policies, with roles defined as collections of capabilities and privileges required to perform job functions. The purpose of this paper is to address the activity assignment problem through a competency-based approach. In this context, an ontology-based competency model is developed to assist in identifying the competencies that exist in an organization and the competencies required, by workflow activities and in performing a competency gap analysis as a prerequisite for domain-specific user development through competency-based training. Design/methodology/approach – An approach for developing a business process activity assignment policy based on an ontology-based competency model is presented. This model is also used to define domain-specific training courses that enable users meet the competency requirements of process activities. In broad terms, the approach consists of the following steps: identification of the competencies required in order to perform the various activities involved in each business process and definition of roles based on these competencies; identification of the competencies acquired in the organization and assignment of users to roles; performance of competency gap analysis to identify the missing user competencies for role playing and identification of user development needs; and development of competency-based training scenarios intended to fill the user competency gaps. Findings – An experimental implementation of the ontology-based competency model proposed in the banking domain provided a fine-grained role structure that was based on the competencies required by business process activities, and a user-to-role assignment that closely matched the competencies required for role playing, and brought forward missing user competencies that pointed to required user training needs. Originality/value – The proposed ontology-based competency model fulfils the need for a sustained work assignment approach based on user roles. To this end, roles and users are defined as collections of required and acquired competencies, respectively. A novel approach based on ontology-based competency ontologies was also developed to fill required but missing user competencies. Keywords Competences, Work flow, Modelling, Training Paper type Research paper

Introduction In recent years, business process management (BPM) has emerged as an important discipline which is concerned with the modeling, evolution and automation of business processes (Currie and Willcocks, 1996; Haux et al., 2003; Lenz and Kuhn, 2004; McAdam et al., 2005; Rutner et al., 2003). Thus, BPM reflects the desire to continuously improve organizational performance by designing new or redesigning existing processes with the objective to improve current work practices (Reijers and Mansar, 2005). In this context, it is important to develop an effective work assignment policy whereby process activities are assigned to proper individuals, who are requested to perform work in order to achieve the objective of the activity (Moore, 2002; Muehlen, 2004). This paper addresses the work assignment issue from the competency management perspective.

PAGE 72

j

JOURNAL OF KNOWLEDGE MANAGEMENT

j

VOL. 12 NO. 6 2008, pp. 72-88, Q Emerald Group Publishing Limited, ISSN 1367-3270

DOI 10.1108/13673270810913630

‘‘ In a workflow environment, roles can be seen from two perspectives: from the user perspective roles represent the combined capabilities and privileges of workflow participants; from the workflow perspective roles represent the capabilities and privileges required for the proper execution of workflow activities. ’’

In the definition of a business process, activities are bound to elements of the organizational model rather than to specific individuals (also called users, process performers or process participants). Business process activities and users are often linked through the construct of role, which may be defined as a job function describing the authority and responsibility conferred to users that are assigned to it (Casati et al., 2001; Muehlen, 2004). Thus, the performance of process activities is associated with roles, and users are assigned to one or more roles. This approach decouples the definition of the business process from the definition of the users, adding to process robustness since changes of users in the organizational structure do not affect process definition. In addition, roles are often used in defining organizational security policies and role-based authorization models are developed to reduce the number of the necessary authorizations and simplify security administration (Casati et al., 2001; Ferraiolo et al., 2001; Sandhu et al., 1996). Hence, a role-based work assignment policy is mainly concerned with defining roles and with assigning users to roles and roles to process activities according to certain criteria, such as the user knowledge, skills and experience, the organizational unit they belong to and their level of seniority. Business process automation through a workflow management system (Workflow Management Coalition, 1999) requires the definition of a workflow model as a computerized representation of the business process model whereby workflow activities are associated with business applications that directly follow the execution logic of the underlying business process (Casati et al., 2001; Thomas and Sandhu, 1997; Wu et al., 2002). Thus, role holders (users) are required to actively contribute to the goal(s) of a business process by being involved in the execution of the corresponding workflow process as workflow participants. In addition, role holders are authorized to perform all of the operations (or methods) included in the activities assigned to their roles (Thomas and Sandhu, 1997). Hence, roles and workflow activities should be defined at the appropriate level of granularity to meet the security and usability requirements specified for the workflow system, including security administration, system performance and ease of use issues. To this end, roles may be structured hierarchically so that the higher roles are responsible for a super set of the activities of the lower roles. On these considerations, the objective of this paper is twofold: 1. To develop a competency model for the required competencies by a workflow definition and, based on this model, to define the roles assigned to the workflow activities in a many-to-many relationship. To remain consistent with the role structure of the organization, fine-grained workflow roles are related to broader organizational roles through a role hierarchy, whereby each of the fine-grained workflow roles defined is associated with organizational roles. 2. To develop a competency model for the acquired competencies of the organization and, based on this model, to define the users assigned to workflow roles in a many-to-many relationship. Furthermore, a competency gap analysis is performed as a prerequisite for domain-specific user development through competency-based training.

j

j

VOL. 12 NO. 6 2008 JOURNAL OF KNOWLEDGE MANAGEMENT PAGE 73

Competency-based work assignment policies The development of a workflow system is usually performed in three main phases (Muehlen, 2004; Weske et al., 1999; Wieringa et al., 2003): 1. business process definition (design or redesign); 2. workflow implementation (design or build time); and 3. workflow enactment (execution or run time). During the business process definition phase, the overall process structure is engineered, the resulting workflow model is designed and a role-based work assignment policy is specified. The latter includes the design of the role structure, the definition of the exact user-to-role and role-to-activity assignment relationships and the specification of contextual constraints (Casati et al., 2001; Thomas and Sandhu, 1997). The completed workflow model is input to the implementation phase. During the workflow implementation phase, the workflow process activities are associated with applications and permissions with regard to activity execution and associated data accesses are specified (Lenz and Reichert, 2005; Wu et al., 2002; Yi et al., 2004). The synchronization of activity responsibilities with application data permissions is of paramount importance in this phase. If errors are made regarding this synchronization, activities might be assigned to process participants who have insufficient data access permissions to execute the application attached to a pending activity. During the workflow enactment phase, instances of the workflow process defined are executed. A workflow process may be instantiated several times and several instances may be running concurrently. The workflow enactment service supports instance execution by scheduling activities (as defined in the business process structure) and by assigning them for execution to users based on the roles they occupy (Casati et al., 2001; Thomas and Sandhu, 1997; Wu et al., 2002). This paper is concerned with the business process definition phase focusing on work (in terms of activities) assignment to users using the proxy construct of role. Roles may be defined as named collections of capabilities and privileges representing organizational users intended to perform business functions (Casati et al., 2001; Sandhu et al., 1996; Wu et al., 2002). Privileges and capabilities describe the possible actions a user is permitted and/or qualified to perform. A capability is a direct property of a user and remains associated with him/her even if the position of the user in the organization changes. A privilege is a property of an organizational position that can be occupied by one or more users, who then inherit the privileges associated with the position. In a workflow environment, roles can be seen from two perspectives: From the user perspective, roles represent the combined capabilities and privileges of workflow participants. From the workflow perspective, roles represent the capabilities and privileges required for the proper execution of workflow activities. Based on these two perspectives, a role structure may be designed through two different approaches: 1. using the existing organizational structure (often captured in organizational charts) and performing a mapping between existing users and workflow activities; and 2. using the structure of the activities in the workflow model to determine the roles of the workflow participants. These approaches imply that roles may either be defined on the basis of the organizational structure, independently of any specific workflow model, or on the basis of each workflow model as collections of process activities. The former approach leads to a definition of broader roles, potentially compromising security (i.e. violating the least privilege principle) when used in a workflow process as they may or may not match workflow activities exactly (i.e. the permissions assigned to a role may or may not be exactly those required for the effective execution of an activity). On the other hand, the latter approach leads to a more fine-grained definition of roles for each workflow process, which may be required by the

j

j

PAGE 74 JOURNAL OF KNOWLEDGE MANAGEMENT VOL. 12 NO. 6 2008

organization’s security policy, but provides a larger number of roles in cases where many workflow processes are defined, potentially hampering security administration and system’s ease of use. On these considerations, roles may be defined through a hybrid approach which is based on both the workflow-oriented and the organization-oriented approach. In broad terms, such an approach consists of the following stages: B

Identify the competencies required by job functions and organizational positions and define an organization-wide role structure, based on these competencies, as a partially ordered set represented by a role hierarchy or a role network. The role structure is defined through a recursive application of generalization and aggregation relationships. Thus, competencies are combined into more complex roles where the higher-order roles are responsible for a super set of the business activities of the lower-order roles. The result of this stage would be a definition of roles as encapsulations of the competencies required to occupy certain organizational positions and perform associated job functions.

B

Identify the competencies required by the various business activities that either constitute the business processes represented as workflows or correspond to traditional information system applications, and assign tightly matching roles to business activities in many-to-many relationships. Identify the required relationships and define their semantics. For example, the relationships ‘‘ResponsibleFor’’ and ‘‘Perform’’ may be defined between roles and sets of business activities. The ‘‘ResponsibleFor’’ relationship represents the fact that a role can either perform an activity directly or can delegate responsibility for it to another role. The ‘‘Perform’’ relationship represents the fact that a role can only perform an activity directly. The result of this stage would be a scheme for assigning roles to business activities.

B

Identify the existing user competencies in the organization and perform a competency gap analysis between the competencies required by the various roles and the user competencies that exist in the organization. Assign users to roles in a many-to-many relationship based on a closest match approach. The result of this stage would be a scheme for assigning users to roles.

B

Use the results of the competency gap analysis to define training courses for organizational users with the objective to fill their missing competencies. The result of this stage would be an exact match between the competencies acquired by users and required by roles.

This listing of stages is not intended to imply a once-through process as the control action necessary at any stage may involve significant iteration. In essence, the above approach focuses on developing an activity description of the organization (or part of the organization) and on specifying the competencies required by each activity in order to define roles as collections of required competencies and users as collections of acquired competencies. Then, through a competency match, roles are assigned to activities and users are assigned to roles in many-to-many relationships. Missing user competencies are intended to be filled through competency-oriented training. Figure 1 depicts a static view of work assignment in the form of a class model. While the above approach aims at setting the framework for an effective work assignment policy, it is not concerned with specifying how each stage should be undertaken or whether each stage is the responsibility of a specialist or a user or allocated to a user-specialist group. It is believed that these problems can be tackled most appropriately within the particular organizational context by taking into account the organizational policies and structure. However, a suite of competency-based techniques is described in the next sections within the context of a prototype implementation of the approach in the banking domain. Typically, the user-based competency model is kept separate from the workflow model, and hence from the workflow-based competency model. The division between a workflow model on the one side and a competency model on the other side fosters the separate evolution of

j

j


Figure 1 A static view of work assignment in the form of a class model

both models, since the life-cycle of the user competencies within an organization typically varies from the life-cycles of the organization’s business processes represented as workflows. In addition, this separation enables workflow designers to create new or redesign existing workflow models that are independent of changes in the user competency structure of the organization, adding to their robustness. During the operation of the workflow system (workflow run time), instances of the workflow process are executed by users holding certain roles. While the sequence of activities within a workflow model is relatively stable, the user competency model needs to be constantly monitored at run time to reflect the changes in the user competencies of the organization. These changes can be either macro changes at the user level or micro changes at the user competency level. Changes at the macro level include the arrival and departure of members of the organization, changes of the association between users and organizational units, and the creation of new or the disbanding of existing temporary user groups (e.g. project teams). Changes at the micro level relate to changes in the authorization profile of users such as the granting of additional authorizations or the revocation of temporary privileges, the establishment of temporary substitute relationships, the acquisition of new capabilities by users (e.g. through completion of training classes) and the change of user experience levels. If user assignment to roles takes individual user competencies into account, the integrity of the user competencies used in workflow model execution must be maintained. The change of user’s experience level can be very useful to track in order to allow activity assignments at a fine level of granularity. As a simple measure, the experience level could be based on activity execution histories. In addition to activity assignment purposes, experience data is also useful during the handling of exceptions, such as overdue activities of processes. A hard-coded or automated exception-handling scheme could be used to assign an escalating activity to a more experienced person, if experience information is maintained.

Motivating scenario The basic motivation for this research stems from our involvement in a recent project concerned with the development of a workflow-based information system in the private banking domain. The stringent security and usability requirements of the system motivated this work and provided some of the background supportive information for analyzing and

j

j


defining process activities and user roles on a sustained basis by taking the overall information context of the bank into account. For illustrative purposes, the competency-based approach described earlier is adapted to a sample business process, related to bank customers’ portfolio structuring (or restructuring). This process is depicted in Figure 2 and has been designed using the IBM WebSphere Workflow build-time tool (IBM Corporation, 2005). Suppose that a customer relations officer (CRO) of a bank’s investment accounts unit (IAU) wishes to make a proposal for a portfolio structure to a potential or an existing bank customer. To this end, the CRO seeks expert advice, regarding an appropriate product mix for the customer, by sending a relevant request to the market analysis unit (MAU) of the bank. In response to the request, a specialist market analyst (MA) assesses the customer’s profile and writes a consultation report which he/she sends to the requesting CRO, who eventually prepares the proposal to the customer. This business process consists of three activities (Issue_Consultation_Request, Issue_Consultation_Report and Prepare_Customer_Proposal) which are executed in a sequence by users belonging to two organizational units of the bank (IAU and MAU). These users are assigned the roles of the customer relations officer (CRO) and the market analyst (MA) which are based on the organizational units they belong to (i.e. on the competencies required to occupy the corresponding organizational positions). In turn, the CRO role is assigned the first and the third activities while the MA role is assigned the second activity. In practice, the competencies encapsulated into the CRO and MA roles include, but are not confined to, the competencies required by the three activities of the business process described above. For example, CROs are also expected to perform various other business activities such as to identify potential customers and to conduct regular or ad hoc meetings with their customers. Also, MAs are also expected to perform various other business activities such as to issue periodic reports on the markets they specialize in and to identify financial product opportunities. Hence, by assigning users to these roles in order to perform the three activities of the business process described above would result in granting to these users more permissions than required for effective activity execution, trusting them to implement the security policy of the organization and not misuse the permissions granted. In such situations, there would be a violation of the least privilege principle, which is often required by organizational security policies (Casati et al., 2001; Wu et al., 2002). Similar requirements exist in many workflow application fields, such as healthcare and insurance, where multiple workflow-based and traditional function-oriented applications have been implemented (Casati et al., 2001; Lenz and Reichert, 2005; Malamateniou et al., 1998; Muehlen, 2004).

Design of a competency-based ontology Competency can be defined as the fundamental abilities and capabilities that an employee should have in order to do a job well (Furnham, 1990). However, various other definitions Figure 2 A high-level business process model using IBM WebSphere Workflow

j

j


have been proposed in the literature, such as ‘‘a person-related concept referring to a set of dimensions of behaviour constituting one’s superior performance at work’’ (Mansfield, 1999; Woodruffe, 1991), or ‘‘one’s characteristics that can differentiate significantly between effective and ineffective performance’’ (Spencer et al., 1990). In addition, it has been suggested that competencies should be measurable because they are derived from job analyses, including characteristics such as interpersonal skills, leadership, analytical skills, and achievement orientation (Micolo, 1999). It has been suggested that the competency resource can be categorized in terms of various factors, such as know-how, experiments, capabilities, capacities, personality functionalities, skill and aptitude (Harzallah and Vernadat, 2002; Sicilia, 2006; Trichet and Leclere, 2003). For the purposes of the proposed model, three categories are considered: 1. knowledge; 2. know-how; and 3. know-whom (Harzallah and Vernadat, 2002). Knowledge covers everything that requires preliminary education or training and can be classified into: B

theoretical knowledge (a bulk of well-established information items, not necessarily theoretical or fully formalized);

B

knowledge on what exists (representing the set of knowledge concerning the context or the environment in which a competency is achieved); and

B

procedural knowledge (consisting of procedures, methods and operational modes, which explain how an activity or a process is carried out).

Know-how is connected to the experiment and the business context and can be classified into: B

procedural know-how (which consists of procedural knowledge, controlled and practical application); and

B

empirical know-how (which consists of operational know-how, which is hard to structure and formulate).

Know-whom is an individual characteristic that allows a user to adopt a particular behavior in a given situation and can be classified into: B

relational know-how (a behavior which describes person relations);

B

cognitive know-how (which corresponds to intellectual operations necessary to carry out the activity involved); and

B

behaviors (different qualities than those expressed in the two previous sub-categories and that are expected in a professional situation).

Designing workflow-based competency ontologies Ontologies are collections of concepts, instances of concepts and relations among them that are expressed at the desired level of formality and that are deemed to be important in characterizing the knowledge domain under consideration at the desired level of detail (Sowa, 2000; Gruber, 1993). The development of an ontology is usually a top-down process which starts at the lowest level of resolution considered and finishes at the highest level of resolution which is considered appropriate for the purpose of the ontology-building process (Colomb and Dampney, 2005; Masuwa-Morgan and Burrell, 2004). Broadly, an ontology may be divided into two parts that correspond to two levels of resolution: 1. the upper ontology (which includes the basic concepts and relations); and

j

j


2. the lower ontology (which includes all the concepts, instances and relations necessary for the specific purpose of the ontology). The ontology that follows was constructed using the SemTalk2 ontology editor for MS-Office 2003, a Visio 2003 add-on that provides all the modelling functionality needed to create ontologies complying with W3C’s recommendation OWL[1]. The upper ontology. Figure 3 shows the competency ontology concepts of the upper ontology (lower level of resolution), linked with relations. Concepts are represented in the diagrams as light rectangled nodes, sub-concept relations as directed arrows connecting concepts (from the lower-level to the upper-level concept), relations as directed arrows connecting concepts (with the description of the relation appearing on each arrow) and concept instances as dark rectangled nodes. In what follows, a description of the upper ontology model is provided using ontology concepts and concept instances (both shown in italics) and ontology relations (shown in single quotes). It is assumed that a system is composed of business processes and each business process is composed of process activities (sub-concepts). An agent is analyzed into: user and external agent. Resource is analyzed into role, product/service, information and technology. Competency is analyzed into required competency and acquired competency. Privilege is analyzed into required privilege and acquired privilege. A system ‘is followed by’ a system (to be used in flows), ‘involves’ external agent, ‘is executed by’ a role, ‘uses’ resources and ‘requires’ required competencies and required privileges. An external agent ‘is assigned to’ a role and a user ‘plays’ a role and ‘belongs to’ an organizational structure. An organizational structure ‘belongs to’ an organizational structure (in order to define hierarchies), ‘owns’ and ‘defines’ resources. A role ‘belongs to’ an organizational structure, ‘refers to’ and ‘consults’ a role, ‘requires’ required competencies, ‘owns’ acquired privileges and ‘creates’ and ‘considers’ a resource. Figure 3 The upper ontology for the competency model

j

j


The lower ontology. Figure 4 shows the competency ontology concepts of the lower-ontology (higher level of resolution) linked with relations. The competency categorization described above has been used to analyze both the required and the acquired competencies of an organization. A business process ‘consists of’ process activities. Each process activity ‘requires’ required privileges and required competencies that ‘involve’: 1. knowledge that ‘consists of’: theoretical knowledge, knowledge of what exists and procedural knowledge; 2. know-how that ‘consists of’: procedural know-how and empirical know-how; and 3. know-whom that ‘consists of’: relational know-how, cognitive know-how and behavior. Each process activity ‘is performed by’ a role that ‘owns’ acquired privilege and also ‘requires’ required competencies (with the above categorization of competencies). Each user ‘owns’ acquired competencies (with the above categorization of competencies).

Using ontologies in competency-based work assignment The ontology is primarily designed to be used in performing the following activities: B

define an organization-wide role structure based on the competencies required by job functions and organizational positions;

Figure 4 The lower ontology for the competency model

j

j


B

identification of the competencies required in order to perform the various activities involved in each business process and assignment of roles to process activities based on these competencies; and

B

identification of the competencies acquired in the organization and assignment of users to roles through competency matching.

The organization-wide role structure is defined using the role concept, through the definition of sub-roles, where each higher-order role inherits lower-level role attributes. Therefore, at this stage, the role hierarchies or networks are defined and role required competencies and acquired privileges are defined at the lowest level of the role hierarchy. Each process activity ‘requires’ required competencies that ‘involve’ knowledge, know-how and know-whom, etc. These competencies must be defined per process activity. By defining required competencies at the highest level of resolution in the activities hierarchy, all required competencies defined become required competencies of all the activities of lower level of resolution than the process activity under consideration in the activities hierarchy. Assigning roles (at the highest level of resolution) to process activities using the ‘is responsible for’ or ‘performs’ relation indicates that the role must inherit all the required competencies (including all the sub-concepts or instances) of the process activities the role owns. And this is also applicable to all higher-level roles defined in the role-hierarchy. Acquired competencies are defined per user using the ‘owns’ relation, including all lower level concepts and instances (knowledge, know-how and know-whom, etc.). User to role matching takes place by comparing one-to-one all the required competencies per role to the acquired competencies per user, considering all the attributes defined per competency (level of expertise, role-hierarchy threshold per activity, etc.). Developing user competencies through ontology-based training The process of users’ development is an attempt to improve users’ effectiveness through planned and deliberate learning processes (Mumford, 1986). Competency-based user development is introduced as an additional requirement into the knowledge transformation cycle (Nonaka and Takeuchi, 1995) and, in particular, into the externalization process (where tacit knowledge is transformed into explicit knowledge) that indicates the required knowledge to be transferred to the trainee who owns certain acquired competencies. Competency gap analysis indicates the discrepancies between the required and acquired competencies. Hence, competency-based development may be considered as a filter that limits the knowledge to be transferred to a user. Figure 5 shows how competency is introduced into the knowledge transformation cycle. Training is performed through training scenarios where each training scenario is serving a specific training need. The atomic element of a training scenario may be defined as an atomic testable reusable unit of cognition (TRUC) (Meyer, 2006). Each TRUC is a self-contained unit of cognition that embodies a collection of concepts, operational skills and assessment criteria and is particularly designed to train a user in order to acquire one or more competencies. Therefore each TRUC is a fully reusable element of cognition and as such it can be used by various training scenarios aiming to train users in the competencies served by the TRUC. Most of the existing automated training aids are essentially collections of multimedia objects. These multimedia objects are usually grouped hierarchically (e.g. in units and sub-units), indexed and combined, through hyperlinks, in order to support various training needs. However, these training aids only provide for manipulating and restructuring multimedia objects in order to create training material, serving specific needs, for the knowledge domain under consideration. Hence, this knowledge must be externalized and made explicit by the user in order to become diffused and reusable. The approach proposed in this paper for users’ development utilizes the domain knowledge already stored into the competence ontology and combines it with multimedia objects in order to create ontology-based knowledge networks (training scenarios serving specific

j

j


Figure 5 Competency gap analysis used as a filter in the knowledge transformation cycle

training needs), which are composed of atomic testable reusable units of cognition (TRUCs). Thus, training scenarios (knowledge repository) combine ontology constructs (ontology repository) with supportive multimedia objects (content repository) helping trainees acquire an in depth understanding of the knowledge domain. Figure 6 shows a schematic representation of the three repositories used in the proposed approach. Figure 4 shows the basic ontology constructs designed for the users’ development process. An educational scenario ‘is about’ a business process and ‘consists of’ TRUCs. Each TRUC ‘develops’ one or more of the detailed competencies.

The banking case study The business process shown in Figure 2 consists of three composite activities that can be further analyzed into sequences of sub-activities (i.e. activities at higher level of resolution). For example, the ‘‘Issue_Consultation_Request’’ activity can be analyzed into a number of

Figure 6 Knowledge networks – linking ontology constructs to multimedia objects

j

j


sub-activities, the first of which is the one concerned with identifying prospective investment account customers (Identify_Prospective_Customers).

Competency-based ontology instances Figure 7 shows an instance of the lower ontology described above, where the Identify_Prospective_Customers (PCs) activity is represented as an instance of the process activity concept. Concept names appear in parentheses immediately after the corresponding concept instance in order to show the leading concept, per instance: B

Attract new customers for bank ( process) ‘consists of’ process activities, one of which is identify PCs (activity) that ‘requires’ to understand how to identify PCs (required competency) that ‘involves’ (1) knowledge about bank PCs (knowledge) that ‘consists of’: customer drives in purchasing banking services (theoretical knowledge), banking marketing principles (theoretical knowledge), bank criteria for identifying PCs (knowledge of what exists), sources for tracking downs PCs (knowledge of what exists) and bank procedures to identify PCs ( procedural knowledge); (2) bank’s practical knowledge in identifying PCs (know-how) that ‘consists of’: bank’s policies for identifying PCs ( procedural know-how) and bank’s tactics in identifying PCs (empirical know-how); and (3) individuals’ characteristics for efficient identification of PCs (know-whom) that ‘consists of’: behavioral requirements for efficient identification of PCs (relational know-how), intellectual requirements for efficient identification of PCs (cognitive know-how) and individuals’ personal drives for efficient identification of PCs (behavior).

Figure 7 The ontology instances for the banking business process activity

j

j


B

Each business activity is assigned to a role using a relationship. Therefore identify PCs (activity) ‘is performed by’ a Customer Relationship Officer of IAU (role). By assigning the business activity to the role, the role inherits all required competencies of the business activity. Therefore a Customer Relationship Officer of IAU (role) ‘requires’ to understand how to identify PCs (required competency), etc.

Let’s assume that a specific employee, the bank employee (user) ‘owns’ understanding and experience in identifying PCs (acquired competency). The employee is a candidate for taking the Customer Relationship Officer of IAU (role). Bank employee’s (user) understanding and experience in identifying PCs (acquired competency) only ‘involves’ some of the required competencies of the role, which are: B

knowledge about bank PCs (knowledge) that ‘consists of’: customer drives in purchasing banking services (theoretical knowledge), banking marketing principles (theoretical knowledge), bank criteria for identifying PCs (knowledge of what exists), sources for tracking down PCs (knowledge of what exists) and bank procedures to identify PCs ( procedural knowledge); and

B

individual’s characteristics for efficient identification of PCs (know-whom) that ‘consists of’: behavioral requirements for efficient identification of PCs (relational know-how) and intellectual requirements for efficient identification of PCs (cognitive know-how).

When performing a competency gap analysis between the required competencies for playing the role and the acquired competencies ‘owned by’ the user, the missing competencies of the bank employee (user) are: B

bank’s practical knowledge in identifying PCs (know-how) that ‘consists of’: bank’s policies for identifying PCs ( procedural know-how) and bank’s tactics in identifying PCs (empirical know-how) and

B

individual’s characteristics for efficient identification of PCs (know-whom) that ‘consists of’: individual’s personal drives for efficient identification of PCs (behavior).

Therefore the bank must develop these competencies so that the bank employee (user) will be able to play the Customer Relationship Officer of IAU (role). A competency-based training scenario The users’ development process is also considered in the design of the competency model instances. Therefore in Figure 7 the educational scenario for attracting new bank customers (educational scenario) ‘is about’ attract new bank customers ( process) and ‘consists of’: B

provide theoretical knowledge on customer drives (TRUC) that ‘develops’ customer drives in purchasing banking services (theoretical knowledge);

B

provide theoretical knowledge on banking marketing principles in attracting PCs (TRUC) that ‘develops’ banking marketing principles (theoretical knowledge), bank criteria for identifying PCs (knowledge of what exists), sources for tracking down PCs (knowledge of what exists) and bank procedures to identify PCs ( procedural knowledge);

B

provide practical knowledge on identifying bank PCs (TRUC) that ‘develops’ bank’s policies for identifying PCs ( procedural know-how) and bank’s tactics in identifying PCs (empirical know-how); and

B

evolve individual’s characteristics for identifying PCs (TRUC) that ‘develops’ behavioral requirements for efficient identification of PCs (relational know-how), intellectual requirements for efficient identification of PCs (cognitive know-how) and individual’s personal drives for efficient identification of PCs (behavior).

When the competency gap analysis was performed between the required (by the role) and the acquired competencies (by the user), certain missing competencies were identified. Hence in order to develop the user, he/she must participate in the educational scenario for attracting new bank customers (educational scenario) with emphasis on provide practical

j

j


knowledge on identifying bank PCs (TRUC) and evolve individual’s characteristics for identifying PCs (TRUC) that ‘develop’ the missing competencies. Figure 8 shows a sample training scenario that involves process specific knowledge for bank and is generated by combining ontology constructs (ontology repository) already developed with multimedia objects used by the bank, or other supportive multimedia objects (content repository). As a result, a knowledge-network (knowledge repository) is formed which consists of reusable units of cognition that are combined to serve user training needs. The IAU of bank (organizational structure) ‘defines’ customer identification criteria (information). The MAU of bank (organizational structure) ‘defines’ bank products ( product/service). All the process activities that follow ‘involve’ PCs ( prospective customers) and ‘are performed by’ a customer relations officer of IAU (role) who ‘belongs to’ the IAU of bank. Identify PCs ‘uses’ customer identification criteria (information). Collect PC data generates PC characteristics (information). A sales opportunity is identified when PC characteristics match bank product(s) ( product/service). A proposal/quote ‘follows’ a sales opportunity, ‘uses’ bank X product(s) and generates a PC proposal/quote (information). If the customer relations officer of IAU has a problem in writing the PC proposal/quote for a PC, he/she ‘consults’ the market analyst of MAU, who ‘considers’ PC characteristics and ‘creates’ a consultation report (information) that the customer relations officer of IAU ‘considers’ in writing the PC proposal/quote about the PC. Finally, a sale ‘uses’ a PC proposal/quote and bank product(s). The market analyst of MAU (role) ‘belongs’ to the MAU of bank (Market Analysis Unit). The scenario uses ontology constructs already defined and locally defined instances of concepts. Scenario entities (instances and relations) are enriched with supportive multimedia objects. Figure 9 shows a sample educational scenario generated with the semantic web principles, where the trainee can navigate into the knowledge network, identify all the activities that Figure 8 The training scenario for the banking business process

j

j


Figure 9 The semantic web training scenario generated and the supportive multimedia

constitute a process, all the resources involved and how they relate with specific activities and navigate to supportive multimedia (content). In the specific snapshot the trainee has navigated to supportive multimedia about the bank products instance.

Concluding remarks This paper presents an approach for developing role-based work assignment policies by taking into account the competencies acquired by users and required by business activities. In particular, the approach aims at designing user roles as collections of competencies required by business process activities and assigning users to roles based on the results of competency gap analysis. The latter is also used for designing user training courses. In this respect, an ontology-based competency model was developed and ontology-based training is proposed which is designed using knowledge networks. Intuitively, the approach may be applicable in a variety of business situations due to its adaptability and scalability in various business environments. However, the approach should be experimented on in various situations in order to assess the results produced in both information system security and usability areas.

Note 1. See www.semtalk.com

References Casati, F., Castano, S. and Fugini, M. (2001), ‘‘Managing workflow authorization constraints through active database technology’’, Information Systems Frontiers, Vol. 3 No. 3, pp. 319-38. Colomb, R.M. and Dampney, C.N.G. (2005), ‘‘An approach to ontology for institutional facts in the semantic web’’, Information and Software Technology, Vol. 47 No. 12, pp. 775-83. Currie, W.L. and Willcocks, L. (1996), ‘‘The New Branch Columbus project at Royal Bank of Scotland: the implementation of large-scale business process re-engineering’’, The Journal of Strategic Information Systems, Vol. 5 No. 3, pp. 213-36.

j

j


Ferraiolo, D.F., Sandhu, R., Gavrila, S., Kuhn, D.R. and Chandramouli, R. (2001), ‘‘Proposed NIST standard for role-based access control’’, ACM Transactions on Information and System Security, Vol. 4 No. 3, pp. 222-74. Furnham, A. (1990), ‘‘A question of competency’’, Personnel Management, June, pp. 37-41. Gruber, T.R. (1993), ‘‘A translation approach to portable ontology specifications’’, Knowledge Acquisition, Vol. 5 No. 2, pp. 199-220. Harzallah, M. and Vernadat, F. (2002), ‘‘IT-based competency modelling and management: from theory to practice in enterprise engineering and operations’’, Computers in Industry, Vol. 48, pp. 157-79. Haux, R., Seggewies, C., Baldauf-Sobez, W., Kullmann, P., Reichert, H., Luedecke, L. and Seibold, H. (2003), ‘‘Soarian – workflow management applied for health care’’, Methods of Information in Medicine, Vol. 42 No. 1, pp. 25-36. IBM Corporation (2005), IBM WebSphere Workflow – getting started with Buildtime v.3.6, IBM Corporation, Armonk, NY. Lenz, R. and Kuhn, K.A. (2004), ‘‘Towards a continuous evolution and adaptation of information systems in healthcare’’, International Journal of Medical Informatics, Vol. 73 No. 1, pp. 75-89. Lenz, R. and Reichert, M. (2005), IT Support for Business Processes, Lecture Notes in Computer Science, Vol. 3649, Springer, Berlin, pp. 354-64. McAdam, R., Keogh, W., Galbraith, B. and Laurie, D. (2005), ‘‘Defining and improving technology transfer business and management processes in university innovation centres’’, Technovation, Vol. 25 No. 12, pp. 1418-29. Malamateniou, F., Vassilacopoulos, G. and Tsanakas, P. (1998), ‘‘Developing a virtual patient record using XML and web-based workflow technologies’’, IEEE Transactions on Information Technology in Biomedicine, Vol. 70, pp. 131-9. Mansfield, R. (1999), ‘‘What is competence all about’’, Competency, Vol. 6 No. 3, pp. 24-8. Meyer, B. (2006), ‘‘Testable, reusable units of cognition’’, IEEE Computer, April, pp. 20-4. Masuwa-Morgan, K.R. and Burrell, P. (2004), ‘‘Justification of the need for an ontology for accessibility requirements (theoretic framework)’’, Interacting with Computers, Vol. 16 No. 3, pp. 523-55. Micolo, A. (1999), ‘‘HR managers can survive and prosper’’, HR Focus, Vol. 76 No. 6, pp. 7-8. Moore, C. (2002), Common Mistakes in Workflow Implementations, Giga Information Group, Cambridge, MA. Muehlen, M. (2004), ‘‘Organizational management in workflow applications – issues and perspectives’’, Information Technology and Management, Vol. 5, pp. 271-91. Mumford, A. (1986), Developing Top Managers, Gower, Aldershot. Nonaka, I. and Takeuchi, H. (1995), The Knowledge-Creating Company, Oxford University Press, New York, NY. Reijers, H.A. and Mansar, S.L. (2005), ‘‘Best practices in business process redesign: an overview and qualitative evaluation of successful redesign’’, Omega, Vol. 33 No. 4, pp. 283-306. Rutner, S.M., Gibson, B.J. and Williams, S.R. (2003), ‘‘The impacts of the integrated logistics systems on electronic commerce and enterprise agent planning systems’’, Transportation Research Part E: Logistics and Transportation Review, Vol. 39 No. 2, pp. 83-93. Sandhu, R., Coyne, E., Feinstein, H.L. and Youman, C.E. (1996), ‘‘Role-based access control models’’, IEEE Computer, Vol. 29 No. 2, pp. 38-47. Sicilia, M.-A. (2006), ‘‘Semantic learning designs: recording assumptions and guidelines’’, British Journal of Educational Technology, Vol. 37 No. 3, pp. 331-50. Sowa, J. (2000), Knowledge Representation – Logical, Philosophical and Computational Foundations, Brooks Cole, Monterey, CA. Spencer, L., McClelland, D. and Spencer, D. (1990), Competency Assessment Methods, Hay/McBer Research, Boston, MA.

j

j


Thomas, R.K. and Sandhu, R.S. (1997), ‘‘Task-based authorization controls (TBAC): a family of models for active and enterprise-oriented authorization management’’, Proceedings of the IFIP WG11.3 Workshop on Database Security, Lake Tahoe, CA. Trichet, F. and Leclere, M. (2003), ‘‘A framework for building competency-based systems dedicated to human resource management’’, in Zhong, N., Ras, Z.W., Tsumoto, S. and Suzuki, E. (Eds), ISMIS 2003, Lecture Notes in Artificial Intelligence, Vol. 2871, Springer-Verlag, Berlin, pp. 633-9. Weske, M., Goesmann, T., Holten, R. and Striemer, R. (1999), ‘‘A reference model for workflow application development processes’’, Proceedings of the International Joint Conference on Work Activities Coordination and Collaboration (WACC ’99), ACM, San Francisco, CA, pp. 1-10. Wieringa, R.J., Blanken, H.M., Fokkinga, M.M. and Grefen, P.W.P.J. (2003), Aligning Application Architecture to the Business Context, Lecture Notes in Computer Science, Vol. 2681, Springer, Berlin, pp. 209-25. Woodruffe, C. (1991), ‘‘Competent by any other name’’, Personnel Management, September, pp. 30-3. Workflow Management Coalition (1999), Interface I: Process Definition Interchange Process Model, Workflow Management Coalition, Winchester. Wu, S., Sheth, A., Miller, J. and Luo, Z. (2002), ‘‘Authorization and access control of application data in workflow systems’’, Journal of Intelligent Information Systems, Vol. 18 No. 1, pp. 71-94. Yi, Z., Yong, Z. and Weinong, W. (2004), ‘‘Modeling and analyzing of workflow authorization management’’, Journal of Network Systems Management, Vol. 12 No. 4, pp. 507-35.

About the authors A. Macris is a Lecturer in Management Information Systems at the Department of Business Administration, University of Piraeus, Piraeus, Greece. His current research interests include ontologies, knowledge networks, knowledge management technologies in e-learning, virtual laboratories, ERP Systems, business intelligence and data quality. A. Macris is the corresponding author and can be contacted at: [email protected] E. Papadimitriou received a BSc degree in Informatics and a MSc degree in Business Administration from the University of Piraeus, Greece. She is currently pursuing a doctoral degree at the University of Piraeus, working in the area of business process management with an emphasis on banking. G. Vassilacopoulos is a Professor of Information Systems at the Department of Informatics, University of Piraeus, Piraeus, Greece. His current research interests include information systems, information security, business process management and workflow systems.

To purchase reprints of this article please e-mail: [email protected] Or visit our web site for further details: www.emeraldinsight.com/reprints

j

j
