With RAL and with other techniques described in literature one can specify the conditions to select resources for the assignment to activities (i.e. potential performers). However, in most of the cases the outcome generated with such selection mechanisms is not ordered, which means that all the potential performers have the same likelihood to be chosen as actual performers of the activities during resource allocation at run time.
We define a new WRP called Priority-Based Allocation (R-PBA) in the following way:
Description. The ability to rank a set of resources according to one or more preferences.
Examples.
- Any secretary of the organisation can perform activity Sign, Store and Notify Resolution; however, it is preferable to allocate the activity to somebody that has at least one year of experience and is available at that moment.
- The Request External Resolution activity is executed with the help of a specific software application. As a consequence, it is convenient to allocate it to a potential performer that has skills on it.
- As activity Update Resolution Proposal consists of modifying the initial resource proposal draft, the person that did the draft has preference with respect to the rest of potential performers.
Related Patterns. R-RF (Retain Familiar), R-RMA (Random Allocation), R-RRA (Round Robin Allocation), R-SHQ (Shortest Queue).
Overview. This pattern serves for having a prioritised list of resources that can be allocated to a process activity. Such a list is generated from preferences established by the organisation for that specific activity. Thus, the preferences define a partial order relation over the set of potential performers of an activity.
Context. Even though all the resources belonging to the set of potential performers of an activity are by definition allowed to carry out the work to complete the activity because they meet the conditions required to be assigned to the activity, the actual execution of the activity at run time may vary depending on who exactly becomes the actual performer. This may not be a problem in some scenarios, but can be decisive in others, e.g. where execution time is really important. Hence the advantage of generating a priority ranking of potential performers to decide the order in which resources should be selected for allocation at run time.
Implementation. Support for this pattern is missing in current Business Process Management Systems (BPMSs). For instance, Activiti, WebSphere MQ andBPEL4People offer the activities to a set of resources that meet simple conditions (e.g. they belong to a specific group or play a specific role in the company) and they are later allocated to the first resource claiming them. Activities have a priority indicator, but resources are not prioritised in any way.
Issues. The prioritisation of resources requires priority criteria, that is, the definition of preferences. The key issue related to this pattern is how to express such preferences, which can have different degrees of complexity, from simple preferences based on personal information related to the resources (e.g. age), to composite preferences where the preferences themselves can ranked, i.e., if the first preference is not useful to provide a priorised outcome given the current information, the second preference must be used, and so on.
In addition, to define resource preferences, properties related to the resources of the organisation (e.g. their skills, salary information, personal data, their history information regarding business process execution, etcetera) must be stored somewhere in the organisation, e.g. in the organisational model.
Finally, despite we usually refer to the resources in charge of executing an activity when we speak about resource assignment and resource allocation, there are other functions involved in the completion of an activity (we refer the reader to the definition of RACI matrices for further information about such functions). For instance, there may be a person accountable for the activity, a person that provides support for execution when necessary, and one or more persons that are notified of milestones related to the activity. Thus, the R-PBA pattern can be applied to any of the functions associated to the process activities that are supported by the BPMS. In fact, the current BPMSs increasingly care about supporting the definition and management of such additional functions, e.g. the Generic Human Roles defined in BPEL4People, and the different worklists that can be defined in Activiti to assign resources to specific functions associated to the activities.
Information about Motivation, Solutions, Evaluation Criteria and Product Evaluation can be found in:
C. Cabanillas, J.M. Garc�a, M. Resinas, D. Ruiz-Cort�s, J. Mendling, A. Ruiz-Cort�s, "Priority-Based Human Resource Allocation in Business Processes", ICSOC 2013, in press, 2013.
In order to materialise the use of the R-PBA pattern, we have used a user preference model developed for the discovery and ranking of semantic web services, which is suitable to be applied to this domain and provides high expressiveness. It consists of a hierarchy of atomic and composite preferences defined as an ontology, which allow specifying preferences such as those described in the examples above, among others.
A proof-of-concept implementation developed using the preference model mentioned and RAL to express certain complex preferences, can be found at
http://labs.isa.us.es:8080/cweb/priority.html. The prototype allows defining preferences on the basis of the organisational model shown at the bottom of the page, which represents a company structured in a hierarchy of positions, where people participate in roles on the basis of the positions they occupy. Further information required to test the prototype is shown in different tabs at the bottom of the page, too. Furthermore, the set of potential performers to be ranked can be customised as long as members of the organisation in question are utilised. The outcome produced is a priority ranking according to the preferences indicated. The following four types of preferences are offered by default as an example:
- RAL Expression. This example uses the RAL Ranker to rank resources according to qualitative preferences (e.g. Favorites Preference) about some property stored in the organisational repository including organisational information (e.g. the positions the resource occupies in the organisation) and skills (e.g. knowledge of specific software applications). In particular, the RAL expression "HAS ROLE Account Administrator", is used to prioritise the resources that participate in role Account Administrator.
- Resource Information. This example uses the ResourceInfo Ranker to rank resources according to quantitative preferences (e.g. Lowest Preference) about some property stored in the organisational repository such as personal (e.g. age) or professional information (e.g. salary). In the example provided, the priority is set on the resource with lowest cost.
- Worklist. This example uses the Worklist Ranker to rank resources according to quantitative preferences about the size of their worklist, specifically to allocate an activity preferably to the resource with the shortest worklist.
- History. This example uses the History Ranker to rank resources according to quantitative preferences about the participation of resources in past process activity executions. For instance, this ranking mechanism can be used to rank resources according to the number of times the resource has carried out a certain activity or the average time the resource takes to complete an activity. In the example provided, the resource that has executed the activity most times in the past, has priority for allocation.
Any similar code can be defined to specify further preferences covered by the user preference model described in
J. M. Garc�a, D. Ruiz, and A. R. Cort�s, "A Model of User Preferences for Semantic Services Discovery and Ranking", in ESWC (2), pp. 1�14, 2010
as described in
C. Cabanillas, J.M. Garc�a, M. Resinas, A. Ruiz-Cort�s, "Priority-Based Human Resource Allocation in Business Processes", submitted to BPM 2013.
in order to test this proof of concept. Please, take into account that information beyond that shown in the example scenario is not evident and may not be available in the system.