A Role-Based Approach for Modelling Flexible Business Processes

Abstract

As organisation environments become more complex, business process models have to provide means to suit the flexibility and adaptability requirements at any given time. A rolebased approach for modelling business processes is a natural way to reflect organisational structures and to highlight responsibilities assigned to actors. The purpose of this paper is to improve this kind of approach in order to support flexible business processes modelling. This can be done through introducing the concept of mission. In addition, to make the approach more flexible in changing organisational and functional contexts, we investigate issues related to the delegation and the constraint aspects.

Keywords

• Business Process Modelling
• Flexibility
• Role
• Mission
• Delegation
• Constraint

1. Introduction and motivation

A business process (BP) is defined in [ 3 ] as a set of logically related tasks performed to achieve a defined business outcome. [ 15 ] extends the above definition by introducing the concept of role, stating that a BP is a set of one or more linked procedures or activities that collectively realize a business objective or policy goal, normally within the context of an organisational structure which defines functional roles and relationships. Modelling BPs consists in capturing processes and highlighting significant aspects of the business. During the two late decades, several sorts of techniques and tools dealing with BP modelling were proposed [ 2 ]: traditional input-process-output techniques, conversation-based techniques, techniques based on role modelling, system thinking and system dynamics techniques, and constraintbased representations techniques. Among these techniques, those based on role modelling have the advantage of supporting the well-known separation of duties principle (SoD). “The purpose of the SoD is a policy to ensure that failures of omission or commission within an organisation are caused only by collusion among individuals and, therefore, are riskier and less likely, and that chances of collusion are minimized by assigning individuals of different skills or divergent interests to separate tasks” [ 6 ]. Furthermore, the concept of role not only allows to underline the responsibility of each actor and reflects the organisational structure but also improves the understanding of the way responsibilities are achieved. Adopting role based methods to model BPs is useful, particularly if they are flexible enough to meet BP flexibility requirements, especially organisational, functional and operational requirements.

Nevertheless approaches, dealing with role descriptions, which are used in BP modelling, are not satisfactory to meet flexibility requirements. These approaches, for instance, Role-Interaction-Networks [ 14 ] and Role-Activity-Diagrams [ 11 ], represent roles as sets of ordered activities or interactions: they introduce “swim-lines” to indicate responsibilities of participants; and describe also interactions between pairs of roles, from a source to a target role. In addition, [ 1 ] improves the understandability of BP models by making explicit roles present in BPs. Its main contribution with respect to [ 11 ] and [ 14 ] is to represent explicitly physical objects that a role needs to execute its actions. [ 1 ] represents a role with a rectangle that includes a set of actions, sequential constraints between them, tools and materials that a specialist needs in his craft to perform the actions. Nevertheless, it does not allow this sequence of actions to be performed by actors having different competencies, according to the situations in hand.

There are many definitions of the flexibility in literature [ 13 ]. Flexibility is defined in our approach as the capacity of making a compromise between, first, satisfying, rapidly and easily, the business requirements in terms of adaptability when organisational, functional and/or operational changes occur; and, second, keeping effectiveness. We aim to provide an effective approach for modelling BPs that realizes this compromise. As discussed previously, the concept of role is an expressive means for modelling BPs. Therefore, our reflection will be based on this concept.

This paper is organized as follows: section 2 presents the core of the proposed

approach for flexible BP modelling based on roles and missions. Section 3 investigates some issues related to delegation aiming to increase flexibility. Section 4 provides mechanisms controlling relationships defining flexibility, in order to keep effectiveness of business processes. Section 5 concludes the paper.

2. A role-based approach for flexible business processes modelling

One of the major limitations of the current techniques, based on role and activity

modelling, is that a BP is considered as a set of operations or activities with a preorder. We believe that this feature increases rigidity by imposing an order to perform operations. A significant amount of flexibility can be reached by providing a set of extension mechanisms based on the concept of role.

Organisations are structured as networks of BPs in order to achieve their business

goals. BP can be first analyzed in term of roles played by actors and holding missions.

During the execution of a BP, actors perform missions that specify the responsibilities

and the work included in swim-lines in classical activity-oriented representation formalisms. A mission is similar to the concept of task in OSSAD [ 4 ], i.e. the crossselling between a BP and a role. A business goal is reached by executing a BP which comprises many roles and consequently many missions.

During the execution of a BP, it is an actor who performs operations.

Organisation’s roles and missions are usually more static than actors and operations

are. The central concepts in our approach are the role and the mission. For our point of view, a role is a semantic construct about which business rules and other concepts can be formulated. It can represent competency to realize particular missions, e.g. “an engineer”, and can embody authority and responsibility, e.g. “a project supervisor”.

As shown in Figure 1, each actor belongs to at least one organisational units and is

assigned to appropriate roles based on his responsibilities and qualifications. The concept of mission serves as a link between roles and operations: A mission is defined as a collection of operational goals satisfied by achieving operations. A mission can comprise several operational goals because it is not achieved performing straightforward and continuous operations without any interaction with other roles. The set of operations allowing a role (played by an actor during the process occurrence) to achieve an operational goal is defined by the concept of activity in [ 15 ]. The difference in our proposition is the following: we propose (i) to define this piece of responsibility of a role in the intentional level (operational goal), then (ii) to go deeply in the specification of this operational goal (dealt with as a black box in usual workflow formalisms), and finally (iii) to specify the operations which performance acts on the business objects and allows to achieve the operational goal. satisfies 1 *

* Operation

Acts on

Regarding organisational, operational and functional perspectives, the position of

missions as an intermediary provides a more flexible way to allow an actor to perform an operation than in the opposite one in which roles are directly linked to operations.

As new policies are incorporated, actors can be easily reassigned from one role to

another as usually, but also from one mission (the responsibility of a role in a specific

BP) to another which is not possible using other approaches; roles can be associated

with new missions; and missions can be associated with new operational goals and operations. In addition, missions can be dissociated from roles; operations and operational goals can also be split-up from missions if needed.

In order to hightlight our motivation behind the use of the concept of mission, let

us consider the following situations:

Situation 1: a new organisation is set up and it proves to be necessary to

distribute the responsibilities of each actor differently. • Situation 2: a responsibly has to evolve.

For dealing with Situation 1 and Situation 2, classical approaches require checking

all operation-to-role assignments and modifying them if necessary. This task is time consuming and includes risk of error. However, competitive environments require quick reactions to changes and do not tolerate inaccuracies.

In our approach, to deal with Situation 1, we just have to modify only some

mission-to-role assignments, while actors keep their roles, with new assigned responsibilities. For dealing with Situation 2, we just have to modify some operational goal-to-mission and/or operation-to-operational goal assignments, while roles keep their missions, with new assigned operations.

Our approach allows adaptation with organisational, functional, behavioral and

operational changes easily, rapidly with less error..

In addition, conventional role based approaches define processes in such manner that a given operation op1 should be executed by a specific role r1. However, in special cases, op1 could not be performed by r1. Based on this observation, we identified an additional aspect of flexibility: in a particular process instance, a mission should be able to be performed by selecting one of the roles provided rather than a fixed role. Accordingly, we consider that a BP should be relied to missions rather than operations. So, instead of defining the pre-order of the operations involved in the process, we just have to precise which missions are required for the BP performance. Each process can be considered as a mapping of many roles and many missions with respecting a number of constraints. Each instance of BP is considered as a mapping of many actors and many missions, respecting also some constraints. A mission can be held by several roles in several contexts for flexibility purposes. Several dependencies exist between operations like synchronisation. They can be expressed by using the concept of constraint which will be discussed in the following section.

3. Support of delegation

In this section, we explore the delegation aspect by which the approach we described in section 2, can be enhanced to address better flexibility requirements. We describe in the following the impact they would have on the flexibility capabilities of the existing model.

There has been a considerable work dealing with various aspects of delegation in the literature. For instance, [ 12 ] and [ 10 ] address delegation in a security context, [ 5 ] addresses user-to-machine delegation, [ 10 ] addresses process-to-process delegation in the distributed object environment, [ 7 ] deals with delegation as an attribute of role, and [ 12 ] addresses delegation among the role administrators. Table 1 shows the various forms of delegation we identified. In this paper we focus on actor-to-actor delegation in the context of flexible business process modelling.

One of the main objectives of companies is to better and more quickly meet with the customers’ requirements. In a changing environment, assuming that participants will always act as predefined is inaccurate, because it limits their autonomy and flexibility when changes make inapplicable some predefined conditions. For instance,

Actor -Can-delegateRole-to-Actor

ActorCan-delegateMission-to

Actor

ActorCan-delegateGoal-to-Actor

ActorCan-delegateRole-to-Role

ActorCan-delegateMission-to

Role

ActorCan-delegateGoal-to-Role

RoleCan-delegateRole-to-Role

RoleCan-delegateMission-to

Role

RoleCan-delegateGoal-to-Role

Actor Actor Actor Actor Actor Actor Role Role

Actor Actor Actor Role Role Role Role

Role Role

Role unforeseen circumstances, such as unplanned absences (illness, leaves), require to change actors. It is possible to deal with these situations using delegation mechanisms.

Delegation is often defined as a substitution mechanism of all or a subset of actor’s roles to one or more other actors. No actor can delegate a piece of role. However, in many cases an actor may want to delegate some missions from his/her role. What is more, in some cases, role-to-role delegation is needed. For example, if the “loan manager” is ill, loan manager’s missions and/or operational goals can be delegated to other employees based on role rather than based on actor. For instance, “Evaluating the conditions” and “Preparing the offer” can be delegated to the “loan manager’s Unit-ofdelegation

Role Mission

The relationship means

that : an actor a1 can delegate a role r to another actor a2 an actor a1 can delegate a mission m to another actor a2

Example – Figure 2 George can delegate his role “loan manager” to Maria George can delegate the mission “Loan handling” to Maria

Operational an actor a1 can George can delegate goal delegate a goal g, to “Preparing the offer” to another actor a2. Maria

Role an actor a can delegate George can delegate his

a role r1 to another role “loan manager” to role r2, e.g. to any actor any actor who is able to being able to play r2. play “loan manager’s assistant”

Mission an actor a can delegate George can delegate

a mission m to a role r, “Loan handling” any e.g. to any actor being actor who is able to play able to play r. “loan manager’s assistant”

Operational an actor a can delegate George can delegate

goal an operational goal g “Preparing the offer” to to a role r, e.g. to any any actor who is able to actor being able to play “loan manager’s play r. assistant” Role any actor being Any actor playing “loan member of a role r1 manager” can delegate can delegate the role r1 this role to any actor who to any actor a member is able to play “loan of a second role r2 manager’s assistant” Mission any actor being Any actor playing “loan member of a role r1 manager” can delegate can delegate a mission “Loan handling” to any m held by the role r1 to actor who is able to play any actor a member of “loan manager’s a second role r2 assistant” Operational any actor being Any actor playing “loan goal member of a role r1 manager” can delegate can delegate an “Preparing the offer” to operational goal g any actor who is able to included in the role r1 play “loan manager’s to any actor a member assistant” of a second role r2 assistant”, “Drafting the offer” can be delegated to the “agent”, and “Preparing the loan financial evaluation” can be delegated to the “financial responsible”.

Role Customer

Agent Loan manager

Mission To submit a loan request Loan request handling

Loan handling Actor Jane John Maria Steve Smith George Smith

Role Customer

Agent Loan manager’s assistant Loan manager’s assistant

Financial responsible

Loan manager

Loan manager

Mission Loan request handling

Loan handling

Operational Goal

Registration of the loan request Preparing the loan financial evaluation

Evaluating the conditions

Preparing the offer

Drafting the offer Examples of actor delegation : Case of role level delegation

- Case 1: George wants to delegate his role “loan manager” to Maria Case of mission level delegation

- Case 2: George wants to delegate only the mission “Loan handling” to Maria Cases of operational-goal level delegation - Case 3: George wants to delegate “Preparing the offer” to Maria and “ Drafting the offer” to John. - Case 4: George wants to delegate only “Preparing the financial evaluation” to Smith Examples of role delegation Case of role level delegation - Case 5: Any actor able to play the role “loan manager” can delegate the mission “loan handling” to any actor able to play the role “loan manager’s assistant”. Here, both George and Smith can delegate the mission “loan handling” to both Maria and Steve. whereas role delegation allows both George and Smith to delegate the mission role “loan handling” to Maria or to Steve.

A flexible delegation model, which provides multiple forms of delegation, and

supports flexible role, mission and operational goal level delegation, is needed.

We define delegation as a mechanism that allows an actor who is member of a role r to give all or part of his responsibility to another actor.

For constructing an effective delegation model, we start by identifying various

forms of delegation for instance actor-to-actor, actor-to-role and role-to-role delegation. Each of them can be based on roles, missions and/or operational goals as shown in Table 1. Figure 2 shows several cases of delegation. In Case 1, unit-ofdelegation is role. Case 2 needs that unit-of-delegation has to be mission rather than role. In Case 3 and Case 4 unit-of-delegation is operational-goal. Facets

Duration Level of abstraction

Transitivity

Depth Unit of delegation

Totality

Values Temporal Permanent Instance

Type

Transitive Non-transitive

Limited Unlimited

Role

Mission Operational goal

Total Partial

Explanation An actor may choose to delegate one or more roles to another actor. This might be for a limited period of time, such as a vacation, or under specified circumstances, such as when the former actor is unavailable. The actor may want to, permanently, delegate some roles and/or missions to others actors, in order not to have to renew this capacity unceasingly.

In the case of an instance level delegation, a delegate receives the capacity to carry out a set of operations (operational goal or mission) to execute particular instances of a BP. In the case of a model level delegation, this is applicable to all instances of a BP.

A delegatee can delegate some of the missions he/she received by delegation from a first actor to a third actor and so on.

It is possible to define the maximum value for the levels of sub-delegation.

Unit of delegation can be a role, a mission or an operational goal.

A delegator may want to delegate the total package of missions embodied in a given role. He can also delegate some of his missions and preserve, for example, only the most complex cases.

4. Constraints on the relationships defining flexibility

This section discusses various types of constraints which are relevant to business processes modelling. In particular, we focus our discussion on numerous constraints (i) applied to the relationships between the concepts of our approach’s core (introduced in section 2) and (ii) related to delegation (introduced in section 3).

• Constraints on the relationships between the concepts of the approach’s core In order to deal effectively with the BP flexibility, relationships between the concepts of our model (c.f. Figure 1) should be controlled to ensure the usability of the provided flexibility mechanism. Figure 3 shows the constraints proposed for the control mechanism. Even if our concepts add flexibility, controlling relationship between them is necessary to keep effectiveness of processes. Indeed, no one can do everything. For instance, it is indispensable to avoid situations in which, an employee gets to approve his own loan request.

Constraints controlling separation of duties: separation of duties is a business technique trying to minimize fraud by dispersing the authority and responsibility for an action over multiples actors. This can be ensured by defining mutually disjoint actor-to-role assignments with respect to sets of roles [ 9 ]. If two roles are recognized as mutually exclusive, the same actor is not allowed to play both roles in order to avoid (or minimize) risks fraud. We believe that constraints restricting mission-torole assignments can provide additional guarantees for the separation of missions. These constraints require that the same mission can be assigned at most to one role in a set of mutually exclusive roles. We can in addition distinguish between: (i) Occurrence-dependent separation-of-duties allowing to support requirement as dealt wit previously (an employee should not approve his own loan request). It allows an actor to play both roles that do not cause conflict of interest when acted on independently, but that produce policy concerns when played simultaneously. This provides enterprise with greater flexibility.

(ii) Occurrence-independent separation-of-duties principles prohibiting the actor to play both roles in any process occurrence enabling to solve potential conflicts of interest issues.

Constraints can apply to actor-to-role, mission-to-role and operational-goal-tomission assignments. They can limit, for instance, the number of members or missions of a role or the number of operational goals for a mission.

Constraints can also apply to processes, and to taked-part-in and participates relationships associated with a BP. Constraints on BPs can limit the number of occurrences of a BP in which an actor can realize missions simultaneously.

Constraints can precise if an actor or a role may participate to multiple business processes at the same time. They can limit the number of process occurrences (belonging to distinct process models) an actor or a role is allowed to participate to, simultaneously.

Organisational

Unit (i) : without flexibility (ii) : with flexibility (iii) : only in the case of delegation of operational goal

Figure 3 : Constraints on the relationships between concepts of the approach’s core

Constraints in delegation model

While delegation can allow dealing with almost all unforeseen circumstances successfully, it has also the potential to lead to chaos if it is applied incorrectly and excessively. Hence, it is highly advisable to provide control mechanisms which limit the undesirable delegation actions according to actor’s competences. For example, a loan manager could be allowed to delegate the mission “validate a loan offer” to his assistant but not to a financial responsible. In addition, the loan manager’s assistant, to whom the responsibility to validate the loan offer was previously delegated, is not authorized to further delegate this mission to someone else. This constraint deals with multi-level delegation.

As mentioned in Table 2, delegation can be transitive. This feature may lead to the

risk that an actor, who is unaware of the qualifications of John, (e.g. Maria) can delegate some missions (e.g. Loan handling) delegated from an initial actor (e.g. George) to a third actor (e.g. John) that may not be qualified for these missions, without the initial actor’s notice (i.e. George). Constraints should be applied to most of the model components and relationships to ensure effectiveness of the provided flexibility mechanism. BP models should thus be extended to support the expression of rules controlling the delegation of roles, missions and operational goals. In our future work, we will study in-depth the constraints applied to the delegation model, such as separation-of-duties in actor-to-actor, actor-to-role and role-to-role delegation.

5. Conclusion and future work

In this paper we have investigated the concept of role in the context of flexible BP

modelling. We have introduced the concept of mission, in addition to role and operation. This concept is missing (except in OSSAD) in existing approaches that deal with roles as the ability to perform a set of operations. We identified a number of challenging issues that we wish to discuss in detail in our future works.

Let us resume the kind of flexibility that our approach introduces with respect to the taxonomy proposed in [ 8 ]. Changes in roles, missions, and operational goals can be done at the BP type and instance level. The subject of change can be associated with organisational, functional, behavioral and operational perspectives. Finally, the proposed approach has actually the ability to deal with the duration property; indeed, temporal (respectively permanent) delegation can cope with temporal (respectively permanent) changes.

Dealing with delegation mechanisms we have proposed in this paper raises many questions which need further research such as: In which circumstances and contexts those mechanisms can be applied? How to distinguish between delegable and nondelegable roles and missions? How to control that delegation is not ill-advisedly used? How delegation can be revoked? By whom should the delegation authority be managed? Constraints, particularly, constraints related to delegation, needs also to be studied in depth.

Finally, other aspects for flexible BP modelling need to be discussed, like monitoring, delegation across organisational boundaries, role activation during a

process and inheritance relationships, whereby one role inherits missions assigned to a different role.

Heretofore, we have exposed some issues concerning flexibility around the

concepts of delegation and constraints. The work presented in this paper is the first attempt to model delegation based on roles, missions and operational goals for modelling flexible BPs. We have probably not identified all important facets of delegation, but we believe that we identified some significant ones. A comprehensive flexible delegation model for BP will be defined in our future work.

References

[1] Balabko , P. , Wegmann , A. , Ruppen , A. and Clément , N. ( 2004 ) The Value of Roles in Modelling Business Processes . BPMDS'04 . Riga, Latvia.

[2] Carlsen , A. , Klein , M. and Malone , T.W. ( 1997 ) Conceptual Modelling and Composition of Flexible Workflow Models . Norwegian University of Science and Technology, PhD Thesis .

[3] Davenport , T. , Short , J. ( 1990 ) The new Industrial Engineering: Information Technology and Business Process Redesign . Sloan Management Review.

[4] Dumas , P. and Charbonnel , G. ( 1990 ) La méthode OSSAD - Pour maîtriser les technologies de l'information - Tome 1 : Principes, Les Editions d'Organisation.

[5] Gasser , M. and McDermott , E. ( 1990 ) An Architecture for practical Delegation in a distributed System, 1990 , IEEE Computer Society Symposium on Research in Security and Privacy.

[6] Gligor , V. , Gavilla , S. , and Ferraiolo , D. ( 1998 ) On the Formal Definition of Separation-of-Duty Policies and their Composition . In: Proc. of the IEEE Sym. on Sec. and Priv.

[7] Goh , C. and Baldwin , A. ( 1998 ) Towards a more Complete Model of Role . Proc. Of 3rd ACM Workshop on Role-Based Access Control.

[8] http://lamswww.epfl.ch/conference/bpmds06/taxbpflex

[9] Kuhn , D.R. ( 1999 ) Mutual Exclusion of Roles as a Means of Implementing Separation of Duties in a Role-Based Access Control System . ACM Trans. Inf. and Sys . Sec., 2 ( 2 ): 177 - 228 .

[10] Nagaratnam , N. And Lea , D. ( 1998 ) Secure Delegation for Distributed Object environments , USENIX Conference on Object Oriented Technologies and Systems.

[11] Ould , M.A. ( 1995 ). Business Processes : Modelling and analysis for reengineering and improvement , John Wiley & Sons.

[12] Sandhu , R. , Bhamidipati , V. and Munawer , Q. ( 1999 ) The ARBAC97 Model for Role-Based Administration of Roles , ACM Transactions on Information and System Security , Volume 2 , Number 1.

[13] Shi , D. and Danies , R.L. ( 2003 ) Asurvey of Manufacturing Flexibility: Implications For E-Business Flexibility” , IBM Systems Journal 42 ( 3 ), p. 414 - 427 .

[14] Singh , B. and Rein ., G. ( 1992 ) Role Interaction Nets (RINs): A process Description Formalism, MCC.

[15] Workflow Management Coalition. ( 1995 ) WfMC-TC-1003 v1.1 The Workflow reference Model .