Keywords

1 Introduction

A service system [15] is an organization of resources and processes that support and drive service interactions such that the outcomes meet customer expectations. Given that the underlying business processes in a service system are typically knowledge-intensive, the most critical resources in such systems are, arguably, the human resources or knowledge workers. It is common for service systems with knowledge intensive processes to use a pull-based dispatch policy [20]. In such a scenario, workers or resources commit to tasks as compared to push-based dispatch where tasks are assigned to workers dynamically by the system or manually by a team leader. Pull-based dispatch is preferred because resources tend to multi-task and completion times of these tasks are not a priori known. A resource (or service/knowledge worker - we will use the two terms interchangeably in the remainder of this paper) evaluates the task based on available task attributes (description, urgency, customer), and decides on her suitability to commit to the task. The decision making is non-trivial and often knowledge workers, especially novice workers, find it hard to identify tasks that they are most suitable for. An added challenge is the fact that operational efficiencies of workers does not depend on the task alone, but also depends on the context or situation when executing a task. For example, a worker may be very efficient when processing a single task but may do poorly when catering to multiple tasks. Some workers may be effective in teams while other not. Clearly, the context of the task is as important a determinant of task performance as the attributes of the task itself. Hence, the notion of context plays a key role in the decision making. Dourish [5] presents some key characteristics of a context: (1) that it is a body of information and (2) that it is separable from the activity. The context is a body of information that can be specified using a set of attributes that can be observed and collected. The values of these attributes do not change and are clearly distinguishable from features describing the underlying activity of the user within the context. In line with Dourish’s characterization, we define the context to be that body of exogenous knowledge potentially relevant to the execution of the task that is available at the start of the execution of the task, and that is not impacted/modified via the execution of the task. In our work, we use a fine-grained notion of context - i.e., we focus on the context of a task rather than the context of a process. Our proposed approach involves recommendation of tasks to resources taking into consideration the context of the resource and the task. To this end, we build a context-aware recommender system (CARS). The input to the system is data from historical executions of tasks by resources annotated with contextual information (some of which are inferred) and the outcome of the execution (a set of performance indicators or non-functional attributes defined for the task). The recommender predicts the suitability of a task for a resource, by providing a rating indicative of the resources’ operational performance on that task. Prediction is based on the assumption that resources who have similar ratings on similar tasks, under similar context, are likely to be rated similarly on other similar tasks. The approach that we propose is of considerable practical value. Conventionally, the decision taken by a resource (in many practical service system settings) is based on human judgment, experience and on her implicit understanding of the context. Consequently, task allocation activity is subjective and relies on the experience of a resource. Automated, data-driven support can potentially serve as a game-changer in these settings. The paper is organized as follows. Section 2 presents overview of concepts used in our work. Model elements of CARS are outlined in Sect. 3, and a detailed empirical evaluation is presented in Sect. 4. Related work is presented in Sect. 5, followed by conclusions and future work in Sect. 6.

2 Overview

This section presents an overview of the approach and discusses pull-based dispatch policy commonly used in a service system, collaborative filtering and context awareness in recommender systems.

2.1 Pull-Based Dispatching in Service Systems

When a service system adopts a pull-based dispatching policy, a work request or task instantiated in the system enters a common queue and remains there till a knowledge worker or resource commits to the task. Every knowledge worker is able to peek into the common queue and view the tasks they are authorized to work on, based on their roles and organizational positions. Workers evaluate the type of task, their suitability to execute the task and other factors to decide if they should commit to a task or not. Once a task is committed to, performance measures associated to the task need to be met (target completion time, degree of customer satisfaction and so on). While experienced workers in the system, learn to identify tasks that they are best suited for, novice workers need help in identifying suitable tasks. Incorrect decision making results in a worker placing work back into the queue or leads to a longer completion time or poor degree of customer satisfaction. A recommender system prioritizing tasks suitable for a worker, would reduce erroneous dispatching decisions.

2.2 Collaborative Filtering Based Recommender System

Collaborative Filtering (CF) is a technology that has been widely used in e-commerce applications to produce personalized recommendations for users [8]. Functionally, CF builds a database of preferences or ratings done by distinct users on specific items. As indicated by Sarwar et al. [23], given a list of m users \(U = \{u_1, u_2 \dots u_m \}\) and a list of n items \(I = \{i_1,i_2, \dots ,i_n\}\), each user \(u_i\) has a list of items \(I_{ui}\), which are already rated. Here, rating is a totally ordered set. A CF algorithm provides recommendations in following ways:

  • Prediction, a numeric value, expressing the predicted preference or rating of an item for a user. This predicted value is within the same scale as the rating values provided by user.

  • Recommendation, a list of items, that a user will like. The recommended list is on items that have not been already rated by the user.

The key in CF is to locate other users with similar profiles to that of the user for which the recommendations need to be provided (or the active user). These similar users are commonly referred to as ‘neighbors’. The similarity weight \(w_{a,u}\) between the active user a and neighbor u, is defined by a similarity measure (e.g., Pearson correlation coefficient). The prediction of user a, rating on item i is done by computing a weighted average of the ratings, using the similarity weight as given in [8] is:

$$\begin{aligned} p_{a,i} = \bar{r_a} + k \sum _{u=1}^{n} (r_{u,i} - \bar{r_u})* w_{a,u} \end{aligned}$$
(1)

where n is the number of best neighbors chosen and k is a normalizing factor such that the sum of absolute values of the weights is 1. \(r_{u,i}\) is the rating of user u for item i. \(\bar{r_u}, \bar{r_a}\) are average ratings of user u and a respectively. Hence, with users representing resources, items representing the tasks and rating representing performance outcomes (such as completion times of tasks), CF can be used to recommend tasks to a resource based on ratings of neighbors.

2.3 Context-Aware Recommendation System

Importance of contextual information has been recognized in many disciplines, including e-commerce personalization, ubiquitous and mobile computing. It is important to incorporate contextual information into the recommendation process in order to recommend tasks to resources in certain circumstances. For example, recommending a complex and time consuming task at the start of the work-shift could result in a different performance outcome as compared to recommending the same task, when close the completion of the work-shift. Context-aware recommender systems (CARS) address this gap and use contextual information for providing better recommendations [1]. CARS deals with modeling and predicting user preferences or ratings by incorporating available contextual information into the recommendation as explicit additional data. The ratings, hence are modeled as the function of not only items and users, but also of the context. The input data for traditional recommender systems is based on data records of the form \(\langle user; item; rating\rangle \). In contrast, context-aware recommender systems are built based on the knowledge of contextual information, with data records of the form \(\langle user; item;context; rating \rangle \), where each specific record includes not only the rating of a user on a specific item, but also the contextual information in which the item was rated by this user. In this work, we use contextual characteristics defined for a business process [22] to model context and incorporate it into our context-aware task recommender.

3 Modeling CARS for Service System

The elements of a context-aware recommender system are users, items, rating of users to items, context and the similarity measure to identify neighbors. In this section we model resource, task, context and define similar resources for a service system to build a context-aware recommender for task allocation.

3.1 Resource

We use the resource model described by Muehlen et al. [16] to model resources (user). In Muehlen’s resource model, each resource owns some roles that represents capabilities and privileges to perform tasks, occupies positions in organization units, that further provide privileges to perform task. Model of a resource is essential to ensure that the recommender does not recommend tasks that are out of a resource’s capacity or privilege. A resource is represented by a set of attributes \(D_R\) representing role, position, organization and other relevant information. These attributes characterize the resource and are static - they do not change during the execution of a task. Hence, a resource r is represented by attribute-value pairs \(v_r=(v_r^1, v_r^2 \dots v_r^{D_R})\).

3.2 Task

Item is a task that needs to be completed by a resource. Task is an executing instance of an activity in a process. Task is characterized by attributes of the process instance it belongs to, and the attributes specific to the task. Task attributes are endogenously determined elements (i.e., attributes whose values are determined via the execution of the task) as well as data provided as input to the task. For example, for a task that verifies a loan application, the loan amount would be a task attribute. We use a set of attributes \(D_T\) to denote process and task data in the usual sense, i.e., data provided as input to a process or task, data modified or impacted by a process or task and data generated as output by a process or task. Hence, a task t is represented by attribute-value pairs \(v_t=(v_t^1, v_t^2 \dots v_t^{D_T})\).

3.3 Context

Context is an important model element in our approach. Saidani et al. [22] define a meta-model of context for a business process. The meta-model comprises of context entity and context attributes. Context entities are connected to each other using context relationships. We leverage this meta-model and use context entities such as activity and resource, and their related contextual attributes. We refer to contextual attributes as contextual dimensions (as we further define attributes for a contextual dimension). While previous work has considered context for the overall process, we model context for tasks in the process. Contextual entities and dimensions captured in the model vary with the situation [22] - “There is no context without context: the notion of context should be defined in terms of a purpose.”. Figure 1 illustrates the context model used for the purpose of task allocation recommendation. The contextual entities are task and resource. The generic contextual dimensions for task and resource are defined in the model. In addition, domain specific contextual dimensions would need to be defined and added. An example of a domain specific dimension for a resource would be a ‘number of years in organization’. Task specific contextual dimensions such as time of the day of executing task, the duration of the task and time to finish are self explanatory. Generic contextual dimensions of resource that impact task allocation decisions are presented:

Fig. 1.
figure 1

Context model used for task recommendation

Full size image

  • Workload can be either: number of tasks waiting at the start of execution of a task or the number of tasks that have been completed over a particular period [17]. It defines ‘how busy’ a resource is or has been when committing to a task. \(WL(r,t) \rightarrow N\), where WL(r, t) is the workload of a resource r at time t.

  • Availability indicates whether a resource is available to perform a task within a specific time limitation. Huang et al. [10] define resource availability measure, to predict if a resource is available at some time in the future. A simpler measure of availability of a resource r at time t is \(Avail(r,t) \rightarrow \{true,false\}\), a boolean true or false where the \(Avail(r,t)=false\) if \(WL(r,t) \ge \tau \) where \(\tau \) is defined for a specific task.

  • Competence is the ability to perform a certain type of task [10]. If a resource performs a certain type of task by using lower cost than the others, it means that the resource has a higher competence level than others to perform the task. The cost can be defined based on service system (e.g. completion time, quality). Competence measure as described in [10] is used.

  • Cooperation is the ability of working with other resources. Kumar et al. [13], define compatibility or cooperation as a measure of the degree to which resources cooperate with one another in a process. Cooperation between resources who perform tasks where there are hand offs, is measured as described in [13].

  • Experience is acquired and improved by performing tasks [11]. The number of times a task has been performed and the duration or time period for which the task is performed, is used to measure experience.

  • Preference is acquired knowledge or attitude to do a certain kind of task. For example, if a resource commits for a type of task frequently, the preference to the task is high. Preference \(\rho (a,r)\) of a resource r on task type a is given as: \(\rho (a,r) = Card(a,r) / Card(a)\), where Card(a, r) is the number of tasks of task type a, resource r has completed and Card(a) is the total number of tasks of type a completed by all resources.

Moreover, each contextual dimension c, can be defined by a set of q attributes \(\{c_1,\dots c_q\}\) having a hierarchical structure and capturing a particular type of context (e.g., experience of a resource). The values taken by attribute \(c_q\) define finer (more granular) levels, while \(c_1\) values define coarser (less granular) levels of contextual knowledge. For example, Fig. 2 presents a two-level hierarchy for the contextual attribute c specifying experience of a resource to a task. While the root (coarsest level) of the hierarchy defines experience on an activity or task, the next level is defined by attribute \(c_1 = \{experience\_case, experience\_customer\}\), which identifies the experience of a resource handling the specific case (other tasks related to the case) or handling a specific customer.

Fig. 2.
figure 2

Hierarchy structure of a contextual dimension

Full size image

An important requirement for building and deploying a CARS is the availability of contextual information along with historical task executions. Our current approach infers contextual dimensions such as preference, workload, cooperation and competence from event logs. Figure 3 provides an example event log containing the details of the task, the resource owning the task, start time and completion time. Using the event data, for any new arriving task, the competence, preference is computed. The workload is derived by evaluating current active tasks of the resource. Similarly, other contextual measures can be computed.

Fig. 3.
figure 3

Extracting contextual attributes for a new task from past execution log

Full size image

3.4 Rating

In CF, users provide ratings to as many items as possible. In this work, the outcome of past task executions is used to compute the rating of a resource to a task. Outcomes are typically performance indicators defined in the service system. Time to complete a task, quality level or percentage of tasks meeting a deadline are some examples of outcomes. Rating is an ordered set and needs to be on a common scale for all users. We use a sigmoid function to compute ratings. The computation of rating for a resource \(r_a\), with completion time of task t as the outcome is given by a sigmoid function:

$$\begin{aligned} R(r_a,t) = \frac{1}{1+e^{-k(\mu _t-\mu _{r_a,t})}} \end{aligned}$$
(2)

where \(\mu _t\) is the mean completion time of the task and \(\mu _{r_a,t}\) is the mean completion time of the task t by the resource \(r_a\). k is a parameter that can be varied to get the required rating interval. In particular, if the variance in outcome is high, k should be smaller to be more sensitive to these variances, similarly, if the variance is low, k should be higher. If there are multiple performance indicators, a rating can be arrived at by selecting from or combining different indicators. The ratings can be further scaled up to a suitable interval of [0,10].

3.5 Resource Similarity

Various similarity measures that calculate the similarity among resources or users, have been defined in the implementation of CF algorithms. Correlation-based similarity of two resources u and v is measured by computing \(Pearson-r\) correlation \(corr_{u,v}\). The correlation between two user’s ratings on common tasks, is used to determine similarity. The correlation used from [23] is as follows:

$$\begin{aligned} s(u,v) = \frac{ \sum _{i \in I_u \cap I_v}(r_{u,i} -\bar{r_u}) (r_{v,i} -\bar{r_v}) }{ \sqrt{\sum _{i \in I_u \cap I_v}{(r_{u,i} -\bar{r_u})}^2} \sqrt{\sum _{i \in I_u \cap I_v}{(r_{v,i} -\bar{r_v})}^2} } \end{aligned}$$
(3)

Where \(I_u\) are items or tasks executed by u and \(I_v\) are items or tasks executed by v. \(r_{u,i}, r_{v,i}\) is the rating of item i by user u and v respectively. \(\bar{r_u}, \bar{r_v} \) is the average rating of the user u, v respectively. Once the similarity is computed, k neighbors are selected and the prediction of a rating on task i for a resource u is arrived at by computing the sum of the ratings given by the neighbors users. Each rating is weighted by the corresponding similarity s(u, v).

3.6 Context Aware Recommendation of Tasks to Resources

Information of the resource, task and context is used to predict the rating. Formally, with the multi-dimension data model, \(D_R\) and \(D_T\) are the dimensions of the resource and task respectively. The dimension \(D_R\) is a subset of Cartesian product of some attributes of the resource. For example, a resource dimension is defined as \(Resource \subseteq Name \times Role \times Department\). Similarly, the task dimension is defined as \(Task \subseteq Name \times Type\). Finally, the dimensions of context such as, \(D_{workload}, D_{time}\) are included (and other relevant contextual dimensions). Given all the dimensions, the rating function F is defined as:

\( F: D_R \times D_T \times D_{workload} \times D_{time} \rightarrow Rating \)

There are multiple approaches to using contextual information in the recommendation process. We use contextual pre-filtering [1]. In this approach, contextual information drives data selection for that specific context. Information about the context is used for selecting relevant set of ratings of the resources to tasks. On the subset of the data selected, rating of a resource to a task is predicted using traditional collaborative filtering technique. Tasks with higher ratings are recommended to the resource.

4 Evaluation

In this section, we present the evaluation of our approach. First, we present the setup for evaluation. Then evaluations on two real-life event logs are detailed.

4.1 Evaluation Setup

In order to conduct our evaluation, we implement collaborative filtering based recommender using Apache Mahout libraryFootnote 1. Figure 4 depicts the procedure for evaluating context-aware recommender system. We use real-world event logs. Based on the identified performance outcome (completion time, quality), ratings are computed for each resource, task pair. The event logs are enriched by computing additional information about context, using information of the task, resource executing the task, the task’s start and end times. We use the data without contextual information and data with contextual information to carry out the validation using random sub-sampling validation. That is, we randomly pick 90 % of data to build a prediction model and use the remaining 10 % to test the model. Ten random splits were evaluated. In the approach without contextual data (marked as 1), rating of a task for a resource is predicted and compared with the actual rating. In the context enriched approach, additional contextual information is used to predict the rating of a task for a resource under that specific context. The predicted and actual ratings are compared and the mean absolute error (MAE), commonly used for evaluating CF is computed [9].

4.2 Incident Management Event Logs

To validate the effectiveness of using context in a real-life business process providing services, we use 2013 edition of the BPI challenge event log of Volvo IT services [4]. The log (Event log1) contains events of an incident management process. Each incident is a task that relates to a glitch in a product. An IT service personnel or resource works on the incident and restores service. The event log contains the information about the product associated to the incident, impact of the incident, resources who worked on the incident, time and status of the incident. Product related to the incident is used to categorize tasks or items. In the log, there is not much information about resource other than name of the resource. We enrich the logs with additional contextual information: workload and preference of a resource. The workload of the resource at a specific time, is computed by evaluating the number of active incidents in the queue of the resource at that time. The preference for task (item) is the ratio of the number of tasks executed by the resource and associated to the product, to the total number of tasks associated to the product. Service levels attained for an item (outcome) is used to compute ratings. Hence, we use a sigmoid function by considering percentage of incidents that were completed within a target time. For predicting ratings, we consider only a subset of incidents where one single resource has worked on it. There are 110 resources, 41 tasks. k or number of neighbors for predicting rating is set to 10. Event logs involving multiple resources, do not provide clarity on the time spent by each resource on an incident and hence are not used. The mean absolute errors for completion time with and without context is shown in Fig. 5.

Fig. 4.
figure 4

Evaluation procedure

Full size image
Fig. 5.
figure 5

Mean absolute error of predicted rating

Full size image

4.3 Financial Institute Event Logs

Our second study uses event logs of 2012 edition of BPI challenge (Event log 2), taken from a Dutch financial institute [2]. The event log represents an application process for a personal loan or overdraft. The amount requested by the customer is indicated as an attribute in the logs. While there are over 1000 events present in the log, we evaluate events that indicate manual effort exerted by the bank’s staff. The manual effort is limited to 6 tasks. Task name and amount of loan requested are used as task attributes. There is no additional information about the resource. Resource who have executed at least 100 cases are considered. Hence, the we have 288 tasks and 43 resources. Number of neighbors is set to 10. Workload of a resource at a specific time and preference of a resource to a task is computed from the log. The rating is computed based on the completion times of task. We predict rating of a task for a resource with and without contextual information and compute MAE as indicated in Fig. 5.

4.4 Discussion

The results of evaluation indicate that the ratings of a task for a resource are influenced by context. As shown in Fig. 5, for event log 1, there is an improvement in prediction accuracy with additional contextual dimensions. However, in event log 2, addition of workload improves prediction accuracy while inclusion of workload and preference does not lower the mean absolute error. In this work, we have used a memory based collaborative filtering algorithm. A model based algorithm would help in identifying the influence of contextual dimensions on the performance outcome or rating. The event logs were collected for a time period of 3 months or less, and hence is limited as CARS requires sufficiently large data that captures ratings in varying situations. Hence, measuring and using additional contextual dimensions on a larger event log would be a useful activity. The models built for evaluation do not contain any domain specific contextual dimensions (due to lack of any additional information other than the log). It would be useful to build a model on a service system including domain specific contextual dimensions.

In real-world recommender systems, there could be a possibility that none of the resources are suitable for a task in their specific context. The task would be rated low for all resources. Such a situation could lead to a task not being picked up or completed on time. For handling such scenarios, additional alert mechanisms have to be built into the service system, to identify tasks that have rating below a specific threshold for all the active resources.

5 Related Work

Our work lies at the intersection of multiple research areas: contextual modeling in business process, resource behavior (used as context in our work), and task allocations.

Context Modeling in Business Processes: Modeling of context in business process has been proposed by Saidani et al. [21]. They introduce a taxonomy of contextual information for business processes consisting of four categories: (i) context related to location (ii) context related to time (iii) context related to resources and (iv) context related to organization. In their more recent work [22], a meta-model for context has been defined. The meta-model comprises of context entity and context attributes. Context entities are connected to each other using context relationships. We have leveraged this meta-model in our work, we use context entities such resource, task and their related contextual attributes or dimensions.

Ghattas et al. [6, 7] use process context and process outcomes from execution histories to discover decisions taken in the past. In their work, the authors model the process context and outcomes. The definition of context is based on a Generic Process Model defined by the authors where, external events, that are out of the control of process execution are referred to as context. A decision tree is built to discover business decisions taken in the past. Our definition of context considers similar external factors.

In our earlier work [25], we use past execution histories and context information to further link with process outcomes and identify resource allocation decisions. However, decision rules are derived by considering all resources of a service system. Derived rules can guide centralized task allocations (push-based dispatch). In this work, the analysis of recommendations are for every resource. Context and outcomes of similar resources are considered for task allocation. Further, the notion of context has been identified for a task as compared to entire process. Hence, the task contains richer information of context specific to itself as well as the entire process.

Process context has also been defined by a different set of authors as “Minimum set of variables containing all relevant information that impact the design and execution of a business process.”[19]. In our work, we consider a more specific definition of context and define some of the contextual characteristics that impact task allocation.

A large body of additional work exists in modeling and designing context-aware recommender systems for e-commerce and mobile systems, but space constraints preclude a detailed discussion of these.

Modeling Resource Behavior or Context: Resource behavior indicators [18], has been defined by Pika et al. In their work, the authors provide a framework for extracting resource behavior indicators from event logs and highlight the change in these indicators over time. Huang et al. [10] present resource behavior measures for competence, preference, availability and cooperation. These measures can be used to characterize resources further. Enriching resource model, to include additional resource characteristics, has also been described in [26]. In this work, we use the resource behavior model to define the contextual characteristics of a resource.

Resource Allocation Recommendation: There is a large body of work on resource allocation. While we present some of the work, the key distinction in our approach is the inherent support it has for pull-based dispatching, where the ownership of picking the task to work on, lies on the resource. In addition, our work provides the ability to consider multiple contextual characteristics that could potentially impact the outcome, when making recommendations.

Recent work by Vanderfeesten et al. [26] propose conceptual extensions to characterizing resource, tasks and process objectives or outcomes. The authors propose the need to extend the resource model with resource characteristics such as its capabilities, experience, preference and personal goals for better task allocation. In our work, we define contextual characteristics of a resource which have some of the resource characteristics and use the same for task allocation.

Cabanillas et al. [3] propose an approach to generate prioritized ranking of resources, based on preferences for task allocation. A preference model is defined and used to generate a prioritized list of resources for a task. The authors indicate the need for a preference model that prioritizes tasks for resources. In our work, we generate a ranking of tasks for each resource.

Much of the work has considered resource characteristics in isolation. Kumar et al. [13] propose cooperation among the team members involved in the process as a measure, and develop an allocation algorithm to maximize team cooperation. The authors, highlight the need for examining impact of cooperation on throughput and other process outcomes. Sonja et al. [12], define various measures of experience. The authors, further describe an experience breeding model [11], for maintaining experience levels of the resources. Detailed modeling of experience enables better evaluation of resource allocation decisions. In this work, experience has been defined as one of the contextual characteristics of a resource. In their work [17], Nakatumba et al. have analyzed the influence of workload on service times. The authors use event logs to extract service times and workload on a resource and build a regression model using workload as a single predictor of service time for every resource. Recommender system proposed in our work, learns from similar other resources, in the absence of sufficient information for a resource and uses multiple contextual characteristics in addition to workload.

Recommending the next action to take, based on a user’s current execution history and specific goal, has been described in [24]. The approach evaluates past history of executions to mine recommendations. The work focuses on the control flow and the context is not considered. In one of the recent works [14], the authors present a general framework to derive and correlate process characteristics. The framework does not consider contextual characteristics of process, resources, and its influence on the process outcomes.

6 Conclusion and Future Work

This paper shows how history of past task executions and their associated contexts can be mined to provide guidance in recommending suitable tasks to resources. Research in the past has analyzed resource behavior or context, but in isolation. The work presented here, uses it in conjunction with outcomes and provides guidance by identifying outcomes of similar resources in similar context. This work further uses real-world event logs to derive resource context and discover influence of the context on performance outcome of tasks. In this work, we have used memory-based collaborative filtering. We would in future, evaluate model based collaborative filtering that creates a model by learning and finding hidden patterns and features in the data. Model based filtering is more robust to sparsity of data, that arises when using context as a pre-filter.