Keywords

1 Introduction

A business process management system (BPMS) coordinates the flow of work between the resources of an organization. An important function of these information systems is to allocate resources to perform activities. This system function is often called resource allocation [1], actor assignment [2] or role resolution [3]. Current resource allocation mechanisms are basic though, because they only consider general organizational information, such as the role, position or business unit of a resource [4]. This proves problematic, because significant variation can be found between resources in the same role, position or business unit [5].

It has been shown that improved resource allocation can lead to improved process performance [6]. More specifically, it is suggested that resource characteristics can be used for advanced resource allocation [7]. Although the potential benefit of more advanced resource allocation based on resource characteristics is generally accepted [8, 9], guidance on the specification of resource characteristics is lacking. We address this deficiency in the form of a step-by-step method to specify resource characteristics, using a well-established taxonomy of human abilities. We then show how the specifications are used to execute more advanced resource allocation. Figure 1 shows the extension, from basic resource allocation based on role, to a more advanced mechanism making use of abilities in addition to role. Instead of selecting any resource with a certain role, additional information is queried to select a specific resource with that role.

Fig. 1.
figure 1

Introduction of characteristics as additional criteria for resource allocation.

Full size image

As proof of concept, the extension is used to for run-time allocation of resources based on the specification of tasks and resources in a BPMS. The resource allocation is accomplished in three phases. First, finding all resources that are available and have the appropriate role to perform the task under consideration. Secondly, determine which resources, from the previously found set, are eligible to perform the task, i.e. which resources possess the required abilities to perform the task. Thirdly, selecting a single resource based on a predetermined process objective, e.g. maximize throughput or process flexibility. Figure 2 illustrates the three-phased resource selection approach.

Fig. 2.
figure 2

Three-phased selection of resource, with an eligibility check and prioritization.

Full size image

To evaluate the method, we present a case study in a factory. A manufacturing environment is particularly well-suited because manufacturing tasks require a large range of abilities (e.g. physical and sensory abilities, in addition to cognitive abilities).

The structure of this paper is as follows: Sect. 2 presents a summary of related work on resource allocation in BPMSs. In Sect. 3 we motivate the use of abilities, as opposed to other human characteristics. In Sect. 4, the method to describe tasks and resources is elaborated and in Sect. 5 we show how the resulting information is used for run-time allocation. In Sect. 6 we discuss the results of the case study and finally in Sect. 7 we reflect on the research and consider next steps.

2 Related Work

BPMSs lead process instances (also called cases) through the activities of a business process according to the process model, by coordinating the resources that execute those activities [7]. A resource, in this context, is any entity that can perform an activity, either alone or in collaboration with other resources, including humans, information systems and cyber-physical systems (such as robots and autonomous guided vehicles). Resources are requested at run-time to perform a work item, towards the objective of a specific activity for a specific process instance [4]. The topic of this research is the matching of a human resource to an activity of a process, i.e. human resource allocation.

Mechanisms for resource allocation in contemporary BPMSs solely consider organizational information of the resource such as role, department or position for this matching. Researchers have identified the need and benefit of more intelligent allocation based on more detailed and complementary resource information [8, 9], but only few studies elaborate on this. Resource allocation essentially consists of two parts: (1) design-time description of resources and activities such that it is possible to determine which resource can perform an activity, and (2) the mechanism that makes use of the descriptions to allocate resources to activities during process run-time [3].

2.1 Description of Resources and Activities

In addition to the standard organizational information, some manual techniques are used to describe resources, in terms of preferences [1] and job experience [10]. Similarly, approaches to describe task requirements [11] and constraints [12] are also proposed. Kumar et al. [13] presents a model to capture compatibilities between resources to improve collaboration between actors in the same workflow. Oberweis and Schuster [14] present a detailed meta-model for the description of resources and their competence, skills and knowledge. While all these studies present compelling arguments to extend resource description, the content of competence, skills, knowledge, etc. is left completely to the user to define. Cabanillas et al. [15] provide a domain specific language called Resource Assignment Language as a complement to BPMN2.0. This language improves the expressiveness of resource description, enabling more advanced resource allocation, but the content is again left entirely open.

To overcome the lack of guidance on resource description, several researchers turn to process mining to discover information about tasks and resources. Liu et al. [16] show how an event log of manual assignment can be used to semi-automate subsequent assignment. Arias et al. [17] extends the concept to allocate a resource to a block of interrelated activities. Huang et al. [18] show how to measure resource behavior in terms of four perspectives, i.e., preference, availability, competence and cooperation, based on process mining. The results of those measurements can then be used to improve resource allocation. Pika et al. [19] expands the allocation criteria by extracting information about the skills, utilization, preferences, productivity, and collaboration patterns of resources from process event logs. Though process mining is used effectively, these studies are still focused on how to retrieve information, instead of what information to retrieve.

More recently, Arias et al. [20] offers a holistic overview of criteria that can be used in human resource allocation. Their taxonomy distinguishes between nine factors, including role and expertise. Although these factors are identified, the taxonomy provides no guidance on how it should be used to describe resources. For example, expertise is defined to include resource capabilities, competences, skills, and knowledge, but those sub-factors are not further elaborated. In fact, clear guidance on the specification of resources and tasks is strikingly absent throughout the literature. The research presented in this paper provides exactly such guidance in the form of a method to specify the abilities possessed by resources and required to perform tasks.

Russell et al. [21] take a different approach, by defining resource management patterns in relation to the lifecycle stages of a work item. 39 workflow resource patterns are catalogued in five categories: creation, push, pull, detour and auto-start patterns. Creation patterns correspond to the “describing” part of resource allocation, while the remaining four categories correspond to the “allocation mechanism” part. Describing resources in terms of abilities, as presented in this paper, aligns well to ‘Pattern 8: Capability-based allocation’ of the Russell et al. [21] catalogue. This pattern is described as “the ability to offer or allocate instances of a task to resources based on specific capabilities that they possess.” They call for a dictionary of capabilities with distinct names and a range of possible values. Our method includes such a dictionary and gives guidance on how to use it to specify resources and activities.

2.2 Resource Allocation Mechanisms

Resource allocation mechanisms vary considerably, ranging from optimization during planning to run-time allocation. Huang et al. [22] combine resource allocation optimization with process mining to develop an approach which improves with data generated during process execution. Shehory and Kraus [23] present several algorithms to optimise allocation by forming coalitions of agents to perform tasks. In physical industries, such as manufacturing, more emphasis is placed on resource scheduling, due to the inherent constraints of physical resources and their location [24, 25]. Havur et al. [26] consider how dependencies defined during design-time affect resource scheduling. Kumar et al. [5] also advocates that balance must be found between quality and performance, by considering the competence of the resources. Koschmider et al. [27] show that changes to resource allocation may affect the process configuration itself.

The research presented in this paper is more concerned with run-time allocation of resources, instead of planning. Zur Muehlen [4] distinguishes between push and pull resource allocation patterns. Push occurs when the system compels a resource to start working on a work item, while pull occurs when a resource requests a work item from the system. The Russell et al. [21] catalogue of resource management patterns recognizes four categories of allocation patterns: push, pull, detour and auto-start patterns. The run-time allocation presented in Sect. 5 of this article adopts push allocation, specifically ‘Pattern 14: Distribution by Allocation - Single Resource’, because it is better suited to the specific case study. However, using abilities to enhance resource allocation is equally applicable to any of the run-time allocation patterns.

3 Human Characteristics

To elaborate on the eligibility step in the allocation mechanism (illustrated in Fig. 2), we considered the four factors of expertise as defined by Arias et al. [20]: skills, competences, knowledge and capabilities. Skills are specific personal attributes that are largely dependent on learning and represent the product of training in particular tasks, i.e. they are practiced acts [27]. Competences refer to combinations of knowledge, skills, abilities and other characteristics that are needed for effective performance in a wide range of jobs [28, 29]. The starting point for developing competence models usually lies in the organizational goals and job outcomes, rather than the specific tasks to be carried out. Knowledge is the awareness of or familiarity with something, making it specific to a subject or task. Capability is difficult to define, because it simply refers to the ability to do something. Ability is better defined in industrial psychology, as an enduring attribute of an individual’s capability to perform a range of different tasks [30, 31]. For example, whereas ‘written expression’ is an example of an ability, associated skills could be proficiency in LaTeX functionalities or using in-text citations.

Abilities are more general than skills and knowledge, but more focused on the actual tasks than competences. Thus, a single set of abilities may be applicable to various activities or even different industries. Skills and knowledge are highly context specific and practically unlimited in number, impeding their universal applicability. Conversely, competences are not specific enough to support selection of resources for specific tasks. Additionally, abilities have the benefit that they exhibit stability over time, with only gradual improvement with exposure to development stimuli [32].

Various theories and taxonomies are used to describe abilities, mostly related to the cognitive area of human performance [33,34,35,36]. The Taxonomy of Human Abilities of Fleishman [37] stands out, as the most comprehensive taxonomy and its validity is established in various studies [38]. It consists of 52 abilities in four categories: cognitive (21), psychomotor (10), physical (9) and sensory (12) abilities. Cognitive abilities represent the general intellectual capacity of a person. Psychomotor abilities combine cognitive and physical traits dealing with issues of coordination, dexterity and reaction time. Physical abilities focus solely on the muscular traits of a person. Lastly, sensory abilities are the physical functions of vision, hearing, touch, taste, smell and kinesthetic feedback (noticing changes in body position) [39]. Figure 3 shows an extract of the taxonomy of human abilities, with selected abilities in each category. The full list of abilities and their descriptions is available onlineFootnote 1.

Fig. 3.
figure 3

Extract of the taxonomy of human abilities [37], showing selected abilities in each of the four categories.

Full size image

Although abilities are particularly well-suited for human resource allocation, it does not prohibit the use of additional characteristics, such as skills, knowledge or even resource preference. Such characteristics can also be used to select a resource for a task, but this research aims to provide clear guidance on the specification of human abilities by utilizing the extensive knowledge instilled in the Fleishman Taxonomy of Human Abilities [37].

The Taxonomy of Human Abilities is accompanied by a tool to determine the ability requirements of various jobs. The Fleishman Job Analysis Survey (F-JAS) guides experts to determine whether an ability is necessary for a job, how important an ability is for a the job, and on what level the ability is required [40]. This can be done for each of the 52 abilities present in the Taxonomy of Human Abilities.

Figure 4 is an extract of F-JAS, showing the scale for a single ability chosen at random (i.e. the written comprehension scale as one of the 21 cognitive abilities). The specific ability and its description is shown at the top, followed by two scales: one to measure the importance of the ability (A) and the other to measure the required level of an ability (B). The importance of an ability is measured on a 5-point Likert scale. By comparing an applicants’ abilities with the importance of a required ability, a recruiter can determine whether the applicant is suitable for a job. The level follows a 7-point Likert scale to indicate to what extent a certain ability must be possessed by an individual. Reference anchors are provided to help the user determine the required level. The full F-JAS can’t be shown here, but the rating scales for all 52 abilities are available onlineFootnote 2.

Fig. 4.
figure 4

Measurement scale for one of abilities of the taxonomy of human abilities (https://www.onetcenter.org/dl_files/MS_Word/Abilities.pdf).

Full size image

The taxonomy and accompanying rating scale are widely used in human performance studies [41, 42] and it is the foundation of the Occupational Information Network (O*NET), the primary job description database of the United States [43]. The reliability and validity of the measurement scales and anchors are confirmed through several studies [38]. In our research, we explore the use of the taxonomy and rating scale to describe human resources and activities to be performed. While this is not its original intention, it is designed to describe humans in relation to business activities.

4 Method to Specify Tasks and Resources in Terms of Abilities

We adopt the Fleishman Taxonomy of Human Abilities (see Sect. 3) to specify task requirements and resource characteristics. Table 1 shows five of the 52 abilities, giving a broad overview of the taxonomy. The identifiers in the first column match those of the Fleishman taxonomy. The full table is available onlineFootnote 3.

Table 1. Extract of the Ability table showing selected abilities of the taxonomy [37].
Full size table

The proposed method takes a two-sided approach, corresponding to the description of tasks and resources. Figure 5 shows a graphical depiction of method, with three steps each for tasks and resources. To avoid confusion, we use the nomenclature steps, tasks, user and resources. The method is comprised of steps performed by the user. The output of the method are specifications of tasks and resources.

Fig. 5.
figure 5

Depiction of the method to specify tasks and resources in terms of human abilities.

Full size image

The presented method was evaluated in a manufacturing case study. To make the method more relatable, we use this same case study as a running example. Figure 6 shows the process model of the case study scenario. The description of tasks and resources can be done in any order, but at least one task and two resources must be specified, otherwise resource selection is superfluous.

Fig. 6.
figure 6

Case study process with five tasks, used as reference to explain the method.

Full size image

4.1 Description of Tasks in Terms of Human Abilities

The description of tasks in terms of abilities involves three steps: designating tasks for ability-based allocation, selecting abilities required to perform that task(s), and finally specifying the ability-level required.

Step T1: Identify Task(s) which Require Ability-Based Allocation.

Not all tasks will benefit from ability-based allocation. For example, a small factory with a single stamping machine will always allocate stamping tasks to resources operating that machine. During identification, the user needs good understanding of the selected tasks.

Selecting a task implies that the user must be able to determine which abilities are required to perform the task, and at what level those abilities should be rated. This can be particularly problematic if task variations exist in an enterprise. It is essential that the user can identify and scope a task such that its required abilities can be specified for all conditions. Table 2 shows an entry for each task of the process shown in Fig. 6.

Table 2. Tasks that require ability-based allocation for the case study process.
Full size table

Step T2: Select Abilities Required to Perform the Task.

The second step of the method will be performed for each task identified in step T1. The user selects the abilities required to perform the task, because tasks rarely require all 52 abilities listed in the Taxonomy of Human Abilities [37]. This necessitates sufficient knowledge of the task to express its requirements in terms of abilities. Eliminating the unnecessary abilities provides the user with a list of abilities that are required for a specific task and reduces the effort needed for step T3 of the method.

Step T3: Determine Required Abilities Level.

F-JAS, as described in Sect. 3, is used to determine the required level of an ability. Step T3 is repeated for each ability selected in step T2. The user uses the references points on the scale to gauge the minimum ability level required and records the result as a value. Table 3 shows the required level of five abilities for the task ‘Prepare change over plate’. The task requires the ability ‘written comprehension’ at level 2, ‘memorization’ at level 4 and ‘problem sensitivity’ also at level 2. The remaining fifteen abilities required for this task are shown onlineFootnote 4.

Table 3. Required level of abilities for the first task in the case study process (extract). The full table is available online (http://is.ieis.tue.nl/staff/ivanderfeesten/Papers/PoEM2018/).
Full size table

4.2 Description of Resources in Terms of Human Ability

Description of resources follow similar steps to the description of tasks, except that here we specify possessed abilities. The method again starts with identification of resources and concludes with determination of the level of each ability of each resource.

Step R1: Identify Resource(s) Available for Ability-Based Allocation.

Not all resources in an organization will benefit from dynamic allocation. Only resources involved in various tasks should be designated for ability-based specification. In our running example, five resources are authorized (based on their role) to perform all tasks in the process. Table 4 shows the five resources and their roles and statuses. Resource status is updated by the BPMS based on task assignment and completion.

Table 4. Resources included in the case study, involved in the tool assembly process.
Full size table

Step R2: Select Abilities Possessed by the Resource.

The user determines which of the 52 abilities in the taxonomy are possessed by the resource. This step requires considerably more effort compared to its counterpart in task description, because a resource possesses a wide range of abilities, including those that are not relevant for some tasks. Counsel from someone with knowledge of the employee’s abilities is recommended.

Step R3: Determine the Ability Level of the Resource.

As with the description of tasks, F-JAS [40] is used to determine the ability levels possessed by resources. Table 5 shows an extract of the ability levels for one of the resources in the case study.

Table 5. Extract of abilities and level possessed by one resource (John) from the case study. The full table is available online (http://is.ieis.tue.nl/staff/ivanderfeesten/Papers/PoEM2018/).
Full size table

5 Run-Time Allocation of a Resource Based on Abilities

The information generated by the method presented in Sect. 4 can be used to allocate specific resources to specific tasks, during process run-time. For the purposes of the case study, the information is captured in data tables of a local deployment of PostgreSQL 10. Figure 7 shows database schema used for implementation. Three main tables are used to define tasks, abilities and resources, whereas two intermediate tables, TaskAbility and ResourceAbility, are used to relate abilities to tasks and resources.

Fig. 7.
figure 7

Data tables used for ability-based algorithm of resource.

Full size image

Based on the design-time specification of resource characteristics and task requirements, the run-time allocation can be supported with a BPMS. In the case study, the allocation mechanism is implemented in Camunda BPMFootnote 5 version 7.8 running on a Wildfly 10 application server. A screencast of the implemented BPMS, accommodating database and operational ability-based allocation is available onlineFootnote 6.

Resource allocation is implemented with a task listener attached to each task designated for ability-based allocation. A task listener triggers a function when a certain event happens in the system. In this case, the event is “task creation”, i.e. when the task is instantiated during process execution, and the function is implemented as a Java method. The system passes the “task_id” from the process model to the method and receives a “resource_id” as the assignee. The following pseudo-code illustrates the implemented algorithm:

figure a

The first line of the algorithm (line A) retrieves the required abilities from the TaskAbilities table (Table 3). In this case, the required abilities of task 1 are retrieved. Line B of the algorithm creates a list of candidates with the correct role. In our case study, all resources satisfy this condition. Line C finds eligible resources, by excluding the resources who possess an ability at a lower level than required by the task (“John” posses “written comprehension” at level 4, while the task requires at least 5). The algorithm attempts to match the possessed abilities in Table 5 with the required abilities in Table 3. In the case study two resources are eligible: Mark and Selma.

If only one eligible resource is found, that resource is set as the assignee (line D). If multiple resources are eligible, it is possible to select a preferable resource, based on process objectives. In the case study, the business prioritizes flexibility over throughput. Thus, the ‘flexible assignment’ heuristic is implemented, by first assigning specialist resources to keep generalist resources available to respond where needed [44]. Generalist in this sense refers to resources with a wider range of abilities, as opposed to specialists who have a narrower focus and usually better equipped for specific tasks. This prioritization is shown in line E. It calculates the average level of abilities possessed by the resource that exceeds what is required by the task. Thus, the calculation determines which resource is better able to perform tasks other than the current task. If no eligible resource is found, the responsible supervisor is informed in line E. Finally, line F returns the “resource_id” and “resource_name” of the assignee to the BPMS.

6 Practical Evaluation of Ability-Based Resource Allocation

The evaluation consists of two parts: (1) application of the method in a real-world scenario and (2) using the data generated by the method to demonstrate resource allocation based on human abilities. The evaluation was done at Thomas Regout International, a medium-sized factory in The Netherlands. The factory uses configurable tools to produce highly customizable metal parts.

Steps T1, T2, and T3 of the method were performed by the operations manager to specify the tasks of the process shown in Fig. 6. This process was selected because all five tasks are performed by human operators and require a wide range of abilities. Afterwards, the operations manager was surveyed and interviewed to evaluate the method itself. The Method Evaluation Model [45] was used as both survey and interview outline. Similarly, the competence manager of the company performed steps R1, R2 and R3 of the method to specify the abilities of five human resources involved in the process. The competence manager was also surveyed and interviewed to evaluate the method from a resource perspective.

The results of the evaluation are not included here due to space limitations, but the full list of questions, responses and discussion points are available onlineFootnote 7. As a brief overview, only three of the 16 questions received negative responses. All three negative responses were related to ease-of-use as perceived by the operations manager. During the interview it was learned that the operations manager found it difficult to relate to the F-JAS scale to rate the required levels of task abilities. However, he also stated that it became significantly easier with subsequent repetitions of the method for additional tasks. The competence manager was highly enthusiastic about the method and even intends to use it for other purposes, such as recruitment and personnel planning.

Utilization of the generated data was demonstrated with the BPMS. The operations manager and process participants were shown how the BPMS allocates tasks to one of the process participants, based on the ability levels. The attraction of automated allocation was enhanced by rendering selected resources unavailable in the system. If the previously preferred resource is not available, the allocation algorithm selects a different eligible resource, from the available pool.

The case study yielded valuable feedback regarding the execution of the method and it showed that the resulting information can be used for run-time resource allocation. The practical demonstration of the method in the manufacturing industry may affect the effort involved though. Manufacturing tasks require a wide range of abilities relative to more administrative tasks. Application in service industries, such as financial services and insurance may involve less effort. Most of the psychomotor and physical abilities will consistently be excluded from analysis. This is equally true for business functions that are more administrative in nature, even in physical industries. The financial and human resource management functions of any organization will also make use of fewer abilities to sufficiently describe their tasks. Depending on the extent of exclusion of certain abilities, it may be advisable to create tailored taxonomies for specific industries or business functions. Tailoring can also help to make the rating scale more relatable.

7 Conclusion

The objective of this research is to enhance the allocation of human resources during process run-time. Current business process management systems employ basic resource allocation, making use of organizational information to find eligible resources for a task. An activity and a set of resources must be assigned to a specific role to ensure that the correct resource is allocated. Roles are abstracted from the resources or activities of the enterprise, comprising an intersection of the two entities. Thus, if the resources or activities of the enterprise change, it may be necessary to re-evaluate the list of roles.

Abilities, as a set of descriptors, have been shown to be more detached from resources or tasks [31]. When introducing a new activity, the required abilities must be determined, but the list of abilities do not change. Thus, the generalizability of abilities allows for looser coupling between activities and resources. More importantly, abilities are specific and quantifiable, enabling the selection of a preferred resource, instead of any resource with the appropriate role. Indeed, the allocation algorithm, as presented in Sect. 5, finds a single resource from a large set of resources.

The contribution of this work is a step-by-step method that guides the user towards resource and activity descriptions. Although many scholars recognize the importance of additional information to enhance resource allocation [7, 8], this research provides the first clear guidance on how to specify such information. The method leverages the wealth of knowledge instilled in Fleishman Taxonomy of Human Abilities [39, 40], but remains simple to perform. The evaluation, as presented in Sect. 6, shows that the method is understandable and useable by business personnel and that it produces data that can be used for run-time allocation of human resources.

The current research can be extended to introduce additional allocation criteria and more sophisticated prioritization or optimization. For example, risks involved in certain tasks can’t be expressed as required abilities or an enterprise may simply want to be more specific, e.g. tasks that require specialized skills. Therefore, the presented method can be expanded to incorporate additional factors, such as skills, experience, preference and authorization. Additionally, more advanced resource scheduling techniques can be introduced to leverage the data produced by the method. Alternatively, the method can be supplemented with a feedback mechanism, where tasks executed by allocated resources generate additional data, such as performance, workload or failure rate.