A Resource Recommendation Approach based on CoWorking History

Recommending the right resource to execute the next activity of a running process instance is of utmost importance for the overall performance of the business process, as well as the resource and for the whole organization. Several approaches have recommended a resource based on the task requirements and the resource capabilities. Moreover, the process execution history and the logs have been used to better recommend a resource based on different human-resource recommender criteria like frequency and speed of execution, etc. These approaches considered the recommendation based on the individual’s execution history of the task that will be allocated to the resource. In this paper, a novel approach based on the co-working history of resources has been proposed. This approach considers the resources that had executed the previous tasks in the current running process instances. Then, it recommends a resource that has the best harmony with the rest of the resources. Keywords—Business process; process instance; co-working history; human-resource recommender criteria; harmony


I. INTRODUCTION
Resource allocation is highly relevant to process mining and its applications.This relevance has been an important issue in business process management (BPM) [1].Some researchers have discussed ways to optimize allocating the resources in an organization, to improve its business process [2], [3].They have studied the business process structural features and the way to optimize the available resources to reach the perfect fit for the business needs.Other researchers have described the resource patterns and the correlation between different activities and the available resources [4].In order to allocate resources, a clear set of rules need to be specified at the beginning of the process lifetime, though this can be challenging.In order to better allocate resources, some researchers have provided different resource patterns, e.g.creation, push, pull, detour [4].Some of these patterns, such as push (from system to worker) and pull (from worker to system) patterns, do not rank the process performance [3].
A resource is an important indicator of a business process performance.Resources can be machines, manpower, money, software, etc.The process of allocating the human resources can be optimized by analyzing their behavior and mining the event logs to find the rules and the different resource patterns.These resources need to be allocated dynamically to improve the efficiency of the process performance in BPM through a resource recommendation approach.
The main contribution is a resource recommendation approach based on the co-working history from the event log.This approach considers the resources executed in the previous tasks at the current running process instances.In order to recommend a resource that has the best harmony with the rest of the resources, the proposed approach considers the frequency and the duration criteria.
The remainder of this paper is organized as follows: an overview of our approach that briefly discusses most of the background ideas, techniques and tools used to cover this paper in Section II.Section III covers a discussion of previous work.The contribution in resource recommendation based on the coworking history is discussed in Section IV.Implementation details and evaluation are discussed in Section V. Finally, the paper concludes with an outlook for the future work in Section VI .

II. BACKGROUND
This section starts with some basic concepts about business process management, as well as describing some of the basic definitions used in the resource recommendation approach (the proposed approach).It starts with a brief overview about the business process and its components in section II-A.Then, Section II-B introduces the event log concept as the main input to the proposed approach.Finally in section II-C, the raw performance measure [5] is explained to be used later in extracting the co-working history.

A. Business Process Management
Business processes are used to organize the tasks performed in an organization by different resources [6].The concept of business process has expanded in the domain of BPM [1], where a business process is represented as a set of activities and tasks performed in an organization or crossorganizations.Each business process serves a set of business goals in an organization or in cross-organizations [7].
BPM has several definitions in the community, one of them states that it is composed of a set of concepts, methods and techniques; each of which support the whole business life cycle (i.e.analysis/design, configuration, runtime, and mining) [1].These methods and techniques manage the execution of business processes in a Business Process Management System.Business processes are modeled as a set of activities that transit from activity to another using a control flow.Fig. 1 illustrates a simple example for a travel agency [7], [8], where a customer sends a travel request which will be processed for further actions.The request can be either accepted or rejected by a travel agent, (i.e., a resource in the travel Fig. 1.Travel agency process model [7], [8]. agency).If the request is accepted, the travel agent will reserve both the flight and the hotel for the customer.However, if the travel agent rejected the travel request, the agency will inform the employee about declining the request.This example is graphically presented as a process model using Business Process Model and Notations (BPMN) [?].

B. Event Logs
In information systems, an event log contains all saved events that are related to the implemented activities by the specified resources.An event log is composed of a set of events that are correlated to a set of cases.An event is composed of a set of attributes, which includes the activity name (i.e.task), the resource responsible, and the timestamp of event occurrence, etc (cf.Definition 1).The series of registered events in a case is given the term trace (cf.Definition 2).
Definition 1 (Event): Let C be the set of all case identifiers, T the set of all task identifiers, R the set of all resource identifiers, S the set of all states, and M the set of all timestamps; So, the event e ∈ (C ×T ×R ×S ×M ) represents an occurrence of a state change in a process instance.We can access properties of an event by the dot notation.e.case refers to the case identifier of e, analogously, e.task, e.resource, e.state, e.timestamp.
An event represents an evolution in the execution of a process instance (case), cf.Definition 2. This evolution occurs when one of the task instances (work items) within the case experience has a change of state.For instance, when a work item starts execution, or shows completes, fails, skipped, etc., an event should at least contain information about the case, the task instance, the resource, the type of state change, and the timestamp indicating the time of the event.The resources here refers to human performers involved in the execution of task instances.
Definition 2 (Execution Trace (Case)): An execution trace σ, case, is a sequence of events, σ =<< e 1 , e 2 , . . ., e n >>, where e i , 1 ≤ i ≤ n, is an event as per Definition 1.The event can be e x < e y if e x .timestamp< e y .timestamp.If an event e occurs within a trace σ, it is denoted as e ∈ σ.Also, the dot notation is used σ.e to access event e of the trace.|σ| is used to denote the length of the trace.Finally, an event can be accessed by its position in a trace, σ[i], where 0 ≤ i ≤ |σ|.
An event log contains different attributes.It is a set of cases each of which contains a set of events (cf.Definition 3).In this paper, an event log contains (task instance, resource, state, and timestamp) attributes.All the event logs provide information about the implementation of a single process by the process model [10].

C. Co-working History
In order to determine the significance of the co-working history of a set of resources in an event log, these resources must have clear measures for their performance.Raw performance measure (RW) is concerned with deciding different performance measures for each resource in the execution log [5].It is stated as a tuple for which the measure is calculated.It contains process model instance, case instance, task instance with the resource responsible, number of occurrence for the task performed by this resource within a start and end timestamps, and finally the value of the performance measure.RW can measure a resource with respect to its effective time, waiting time, service time, etc.In this paper, only the effective time is considered from RW as presented in [5].
Definition 4 (Trace History): For a work item t ∈ T , which has an event e, i.e. e.task = t, in a case σ, we define σ <e = e i |e i < e to be a sub-sequence of σ including all events that occurred before e.
The co-working history is based mainly on the event logs.It is one of the key notations that is defined as a task over an event log W (cf. Definition 5).
Definition 5 (Co-working History): For a work item t ∈ T and an event log W , we define W <t ⊆ P(W ) = {{σ v |∃e ∈ σ v ∧ e.task = t ∧ σ v<e is a trace history f or e}}.Moreover, ∀σ x , σ y ∈ W <t : Definition 5 finds t ∈ T the different sets of trace histories that have common tasks and common resources performing them to recommend the resource who will execute the task.
Many studies have identified and classified the main criteria used in resource allocation approaches.These studies aimed at improving tasks performance within the process which are related to the properties of human resources (a taxonomy of resource allocation criteria) [11].These specified criteria are Amount, Experience, Expertise, Preference, Previous performance, Role, Social context, Trustworthiness, and workload.This paper presents a criteria for resources recommendation based on the co-working history, which considers the resources that performed the previous tasks in the current running process instances.This criteria is used to recommend a resource having the best harmony with the rest of the resources.This aspect of co-working history, frequency and duration, as a harmony-based aspect can be inserted among standards of social context, which includes Collaboration, Compatibility, Influence and Social position.This consideration works for the improvement of tasks performance in the process.Fig. 2 illustrates the proposed criteria and their inclusion in the classifications for resource allocation [11].

III. RELATED WORK
In [4], the authors proposed 43 workflow resource patterns, classified into six categories.These categories cover, among Fig. 2. Taxonomy of resource allocation criteria [11].
other aspects, how the resources can be assigned at the processdesign time and how they can be allocated at runtime.Those patterns provide different approaches to identify the eligible resources, as in creation patterns, but they do not provide any means to recommend one candidate over the others.In [12], the authors provide a life-cycle support for the rules of staff assignment based on an organizational model and an event log to discover the allocation rules by learning the decision tree.
In [13], the problem of resource allocation optimization is modeled as Markov decision processes and solved using reinforcement learning.The optimization was fixed to either cost or flow-time based queuing for ordering the queue of work items allocated to each resource.A similar approach is presented in [14].It is worth noting that both approaches considered role assignment at process design time in contrast to resource allocation at runtime which this research aims for.
In [15], the authors applied machine learning techniques on the process logs and process models to extract classifiers about the resource who can execute the activity.These classification models are then used to recommend resources for running instances.In [16], the authors used data mining techniques to support and identify resource allocation decisions by extracting information about the process context and process performance from past process executions histories.
In [17], [18], data mining techniques are used to extract resource allocation rules from process logs.The approach recognizes the so-called dependent resource assignment, e.g., if activity a 1 is executed by resource r 1 , activity a 2 is executed by resource r 2 , then activity a 3 should be executed by resource r 3 .However, it is unclear how the approach would deal with other runtime aspects like workload or the unavailability of the resource.The proposed approach in this research recommends the resource based on the co-working history among other aspects, cf.[19].Then, it adapts to the actual allocation that will take place on an instance level for the recommendation of the next task.Thus, the aim in this research is to introduce flexibility at runtime compared to the rigidness of the extracted association rules.
In [20], the authors have specified the preferences for different resources using expressions based on a Resource Assignment Language (RAL).These preferences are then used at runtime to rank the potential performers of an activity.The concept of providing a list of performers along with their rank is interesting and is of practical relevance.At runtime, it is not helpful to recommend just one resource as he might be engaged in other work or not present.Thus, it is important to provide several alternatives to do not block the process instance waiting for a free resource.In [19], a framework for recommending resource allocation based on process mining is defined.It introduces six dimensions to compare between potential resources and the user who can change the weight of each dimension to control the final recommendation.This approach can be seen as an extension of the work in [20].
Compared to what this research aims to achieve, this proposed approach targets going beyond the one-to-one relation between a task to allocate for a resource by studying the n − ary relationships between groups of tasks and their respective potential performers.
Cooperation correlation among pairs of resources have been introduced and measured in [21].Compared to the proposed approach perspective, the cooperation is applied only on pairs of resources whereas n − ary sets of resources are considered based on the completed tasks within a case.Moreover, the authors have identified resource recommendation as a use case for calculated measures.However, for that specific use case they do not consider cooperation correlation as a criterion for resource recommendation.Rather, they consider resource preferences and competency.A similar approach about resource cooperation is presented in [22].
In [23], the authors have provided the resource allocation method under constraints of preference, availability and the total cost constraints.Then they analyzed the influence of collaboration between resources on process performances.In [24], the authors introduced a method to compute the social relation between two resources; then, they computed the influence of the previous resources on the candidate resources by using a Q-learning algorithm for dynamic task allocation.In [25], the authors presented a model which measures the compatibility among resources when assigning work items to the collaborative groups by using compatibility matrix.They have also developed an allocation algorithm to maximize team cooperation, the needs for inquiring the effect of cooperation on throughput and other process results.

IV. A RESOURCE RECOMMENDATION APPROACH
This section presents the proposed approach for resources recommendation based on co-working history by specifying and applying frequency and duration criteria.

A. Recommendation Criteria based on Co-working History
As in Section II, the proposed approach is based on the coworking history for resource recommendation.It determines the criteria and metrics from the event log and uses them as a new dimension for resource recommendation which has been termed as co-working history.These criteria are as follows: • Frequency Criterion (FC): It recommends the appropriate resource to perform the target task based on the number of times in which the resource works with the previous resources in the same cases at the event log.It is suitable to recommend a resource that works more times with the previous resources in the same cases for the event log to perform the target task; i.e.
(IJACSA) International Journal of Advanced Computer Science and Applications, Vol. 9, No. 7, 2018 the number of times during which the resources work with each other in the same cases in the event log.
• Duration Criterion (DC): It recommends the appropriate resource with less average time to perform the target task based on the previous resources.It is suitable to recommend a resource to perform the target task based on previous resources that has less average time in the execution of the tasks.
Based on these criteria, a resource recommendation approach is needed to find the most appropriate resources to work with previous resources based on co-working history.

B. Calculating Co-working History
The resource allocation based on co-working history approach mainly includes two parts: Part 1, The preprocessing steps: The raw performance measures (RW) are generated from the implementation of the approach presented in [5].Both of the event log and the raw performance measures (RW) are inputs to a set of preprocessing steps to obtain the co-working relationships.After extracting the event log and RW from [5], data preprocessing has been conducted as follows: (1) filter out cases in which sum METRIC-VALUE are less than 0, and cases that contain less than three activities, (2) choose the effective time as a measure for the proposed approach, (3) find the latest resource who performed each activity in each case within the event log and RW, and finally (4) detect whether the resource executes the same activity more than once in the same case.In the last step, the average is calculated as the effective time for the activity.As an output, the event log is ready to be used as an input to the proposed approach.Fig. 3 illustrates how to obtain and calculate co-working relationships.Part 2, Recommending a resource: There are two steps to recommend a suitable resource for working with the previous resources for each activity based on the co-working history.They are as follows: (1) divide the event log into training and testing sets, (2) recommend resources for each activity according to the proposed criteria (Frequency and Duration).

V. EVALUATION
The evaluation of the proposed approach is applied on two logs: 1) Synthesized Log: For the evaluation, a synthesized Log that had been generated from the ProM [26] plugin "Perform a simple simulation of (stochastic) Petri net" [27] was used.This log was taken from [5].It contains 100 cases with a total of 4677 events, 10 activities, and 9 resources.For further references clarification in this paper, this log is referred to as W 1.
2) Real Log: The approach has been applied on a real log from the Business Process Intelligence (BPI) Challenges.The log was taken from a Dutch Financial institute (referred to as W 2), and it contains data that that represent the process of personal loans applications 1 .the log contains 13087 cases with a total of 262200 events, 25 activities and 69 resources.
The proposed approach has been implemented using Java and a relational database.And it has been tested on Windows 8 with 4G RAM and a Core i5 processor.

A. Co-working Effect on Process Performance
The aim of this section is to statistically prove the significance of the co-working relationships (team harmony) on resource recommendation and process performance.Definition 5: The co-working history works on finding, for a given task, t ∈ T , the different sets of trace histories that have common tasks and common resources performing them.Suppose that W = {σ If we consider task t 3 , then the resulting co-working history will be W <t3 = {{ e 1 (t 1 , r 1 , complete, tm 1 ), e 2 (t 2 , r 2 , complete, tm 2 ) , e 10 (t 1 , r 1 , complete, tm 10 ), e 11 (t 2 , r 2 , complete, tm 11 ) }, { e 100 (t 1 , r 7 , complete, tm 100 ), e 101 (t 2 , r 5 , complete, tm 101 ) }}.
Here, traces σ 1 and σ 2 are grouped together because they have a common trace history for task t 3 , the same tasks executed before t 3 with the same human resources.Trace σ 3 is in another set because it deviates from the other two traces with respect to the human resources.
In order to check whether the co-working history affects human resource performance of the task-in-hand, a statistical test was formulated where the statistical significance of such hypothesis was tested.The null hypothesis H 0 is that the harmony (common co-working history) is ineffective and has no influence on the performance of human resources.The alternative hypothesis states otherwise.That is, the co-working history has an influence on human performance.To test the hypothesis, a paired T-Test using unequal variance was applied.For this test, there is need to prepare two sets.The first set contains the time taken by the different human resources who executed the target task t with all cases (traces) in which t was executed.The second set contains human resources who executed t but within cases that have common co-working history.
To explain how the testing works to prove the hypothesis assumption, a set of steps on the event log has been applied: (1) Obtain the process model for the event log, (2) Select cases or traces that contain at least three activities and more, (3) Select the target activity; the chosen target activity is not the first one in the trace but must be preceded by a number of activities to have a co-working history, (4) Find all the resources who execute the target activity, (5) Find the effective time for all resources who perform the target activity for each case in the event log (situation 1), ( 6) Identify specific resources for the target activity, and finding all possibilities for co-working history to all activities that precede the target activity, c.f. Definition 5, (7) Compile similar groups in coworking history of all activities that precede the target activity (situation 2), ( 8) Run the paired T-Test with un-equal variance.
In this paper, the approach in [5] has been used to extract the event log and the performance indicators.To give an example about how the test works, trace from event log for process model was chosen as shown in Fig. 4. Table I illustrates a sample from the event log.After choosing trace, the target activity W −V was selected from the trace shown in Table I.Then, all the resources that perform this activity along with their effective time (18 resources) were provided.This step is referred to as (Situation 1).Table II shows all resources and their effective time in performing the target activity in all cases of the log.Then, W <W −V ,cf.Definition 5 was constructed, which contains the sets of activities that precede the target activity to get the coworking history of the target activity for each resource.This step is referred to as (Situation 2).Table III shows the special groups for each resource in each case according to the coworking history.To give an example, in situation 1, without co-working history for the resource 10629 the effective time according to the target activity W.V in all cases is 32 min in case 173688, 15 min in case 173844, etc., cf.Table II.In situation 2, with co-working history for resources Dummy, 11049 and 10629, the effective time in this group for resource 10629 is 32, 29, 6, 35, 32, 10.5, 25, 32 min in all cases respectively.For the other group in situation 2, The effective time for the resource 10629 in co-working history with 11201 and 11049 is 15, 26, 11; cf.Table III.Each group from situation 2 will be tested against situation 1 individually.Note that the size of situation 1 is not equal to the size of situation 2. The size of situation 1 is larger than the size of situation 2.

B. Process Performance Results
The results stated that there is a certain percentage of each resource confirming the assumption of this research which says that "the harmony among resources with co-working history has an influence on the human resource performance".The percentage, which confirmed the assumption for each resource that has performed the target activity, is calculated using the following equation: www.ijacsa.thesai.orgn is the number of cases where H 0 is rejected and the count of cases for all groups is the summation of the cases for each resource with co-working history (situation 2).And the confidence level (CL) was 95 % when was the default value α = 0.05.Table IV shows the results of the statistical tests for real log and the percentages obtained by each resource in the provided example.These results prove that the test result for all the groups have proven the hypothesis for each resource.As an example, when resource 10629 performed the target activity W −V , 80 groups with 170 cases which have common co-working history were formed.There are 45 groups among the 80 groups that confirmed the hypothesis (i.e., count of groups where H 0 was rejected is 45 groups out of the 80 groups).The number of cases in the 45 groups which confirmed the hypothesis is 70 cases.When (1) was applied on resources, the result of resource 10629, was 70/170 = 41%, 35% for resource 10809, 37% for resource 10609, etc.

C. Implementation and Experimental Evaluation
In this section, the proposed approach is described and applied along with details in order to verify the influence and the effectiveness of the harmony among resources.In order to obtain co-working relationships, the event log is preprocessed and split into training and testing sets (80% for training set, 20% for test set).In this part, the real-life event log (i.e.W 2) was used to test the proposed approach.The approach was implemented in [5] which calculates the RW out of the input event log (Table VI).Table V shows a sample of the event log and Table VI shows a sample of the raw performance measures for cases 205715 and 205721 as an example.The proposed approach needs preprocessing for the current event log in Table V.The event log is filtered using Table VI to remove all cases where the sum metric value for all resources is less than or equal to zero, and using Table V to remove all cases that contain less than three activities.Hence, only the cases that contain three or more activities are considered.Moreover, effective time is used as the main performance metric which is one of the measures extracted from [5].
After filtering both the event log and the raw performance measure (RW) tables, the event log was scanned to find the latest resource who performed each activity in each case within the event log.Then, these resources are linked with the performance measures when the event type = complete.For example, in Table V, the resource 10933 has allocated activity "W − Completeren aanvraag" for case 205721 at time tc = 2 − 1 − 201220 : 26, and the resource 11119 has allocated   After the preprocessing steps, the new event log is used as input for the proposed approach.This event log contains information about 3718 cases, 13704 events, 58 resources and 9 activities.The attributes for each case include EVENTID, CASEID, RESOURCE, ACTIVITY, and METRIC VALUE (Effective Time), cf.Table IX.This table is used to calculate the co-working relationships based on applying (Frequency and Duration Criteria) for recommending the resources based on co-working history.This co-working history verifies the influence of the harmony among resources on the performance of resources, where a significant difference has emerged.The event log data (cf.Table IX) is split into training and testing sets to obtain co-working relationships.The training set is used to extract the co-working relationships using SQL queries, which generate a co-working relationship table.This table is used to recommend the resource based on both (Frequency and Duration Criteria) after applying some SQL queries.On the other hand, the test set is used to compare the results before and after applying the proposed approach.ommendation approach after applying frequency and duration criteria.For example, there are cases where each case records the resource which performs the task.In the case 205733 of the original log, resource10932 executes task W − C, resource 10789 executes task W − N , resource 10138 executes task W − V , and so on.Each resource has an effective time for its corresponding activity (20.00, 0.00, 8.00 min), respectively.
According to frequency criterion for resources recommendation, when the resource 10932 executes task W − C, the appropriate resource to execute task W − N is 11259 with average time (0.00 minute).Hence, when the resource 10932 executes task W − C and the resource 11259 executes task W − N , then the appropriate resource to execute task W − V is 10138 with average time (14.86 min).While according to duration criterion, different resource recommendations are as follows: when the resource 10932 executes task W − C, the appropriate resource to execute task W − N is 10138 with average time (0.00 min).Moreover, when the resource 10932 executes task W − C and the resource 10138 executes task W − N , the appropriate resource to execute task W − V is 10629 with average time (8.84 min).
Another example, in the case 205745 of the original log, the resource 11169 executes task W − Af handelen, the resource 11119 executes task W − C, the resource 10629 executes task W − , and the resource 10629 executes task W − V .Each resource takes an effective time for an (2.00, 19.00, 0.00, min) respectively.X shows the different variations on both frequency and duration criteria after applying the proposed approach.

D. Evaluation Results
The evaluation of the results is based on synthesized and real life logs.In order to investigate whether the proposed approach contributes to get better results and improve the performance of tasks, (2) was used to calculate the overall result applying the approach for the duration criterion.
Overall=Σ n i=1 ETB approach − ETA approach (2) where n is the number of test case, and the overall represents sum of the total difference between before and after the proposed approach application according to the criterion of duration.The Effective Time Before (ETB) applying the approach represents the effective times of activities that resources have performed in the original log.While, the Effective Time After (ETA) applying the approach represents the effective times of activities that resources have performed after applying the criteria.The total of the effective time after and before applying the proposed recommendation approach is computed using the following equation: where n is the number of test cases, and the effective time for each test case (after(A) and before(B)) the recommendation is the summation of the effective time (after and before) applying the proposed recommendation approach.
In (4), the average of the effective time for test set (20%) before applying the proposed recommendation approach was computed.
where n is the number of test case, and the effective time for each test case before the recommendation (BR) is the summation of the effective time before applying the recommendation approach.
In (5), the average of the effective time for test set (20%) after applying the recommendation approach is computed.where n is the number of test case, and the effective time for each test case after the recommendation (AR) is the summation of the effective time after applying the proposed recommendation approach.
Table XII shows the results of applying the proposed approach on real and synthesized event logs.It uses (3), ( 4) and ( 5) on test set (20% of the event log).For the order fulfillment log (W 1), the total of the effective time after applying the approach based on the criteria (Frequency, Duration) is 187384.85min, 159901.054min, respectively.The total effective time of the original log before applying the approach is 9641.052632min.The Avg AR after applying the approach recommendation based on the criteria (Frequency, Duration) is 9862.360526min, 8415.844947min respectively.On the other hand, Avg BR of original log before applying the recommendation approach is 9641.052632min.
For the Financial log (W 2), the total of the effective time after applying the recommendation approach based on the criteria (Frequency, Duration) is 17555.064min, 12804.2593min respectively.The total effective time of original log before applying the approach is 22488.88615min.The Avg AR applying the proposed recommendation approach based on the criteria (Frequency, Duration) is 25.778361 min, 18.8021429 min, respectively.On the other hand, Avg BR of original log before applying the recommendation approach is 33.02332767 min.
The improvement rate of the proposed approach was calculated and evaluated by using the following equation: Improvement Rate = (Avg BR − Avg AR )/Avg BR (6) The results of the proposed approach have an improvement of the real data set and synthesized data set.The results show that the time is minimized to 0.2350476 min with frequency criterion and 0.43064057 min with duration criterion of the real data set.For synthesized logs, the results show that the time is minimized to 0.127082356 min with duration criterion, while the results state that the time is maximized to −11.64778393 min with frequency criterion.The negative value implies that the resources recommendation approach gives bad results.
The real data set has a bigger improvement because it contains a greater number of cases, activities and resources.In other words, considering co-working history for task allocation and resource recommendation is efficient.It also reduces process execution time significantly by taking resource harmony into account.Note that, more satisfactory results can be obtained as the number of process instances increases.The reason is that more event logs can generate more accurate harmony measurement which in turn provides more effective allocation recommendation.

VI. CONCLUSION AND FUTURE WORK
This paper has proposed a resource recommendation approach.This approach is built upon the co-working history from an event log.It considers the resources that had performed the previous tasks in the current running process instances, in order to recommend a resource that has the best harmony with the rest of the resources.This proposed approach focuses on the organizational perspective.It depends on a procedure-approach to extract time-related key performance indicators from process execution logs.This procedure-approach supports four measures: effective, service, waiting and sojourn time.The effective time measured was used in the proposed approach.
The proposed approach works to determine the criteria and the metrics from event log for resource recommendation.These criteria are (frequency and duration) based on the co-working history.The approach has been implemented and tested on both real and synthesized logs.The results show that it is possible to obtain the appropriate resources recommendation based on the criteria of co-working history.This approach has contributed to reducing the tasks time and to improving both the process and the resources performance.
As a future work, the researcher aims to add the coworking history approach as a new dimension and extend the related approaches for the resource recommendation with other algorithms.

Fig. 3 .
Fig. 3.An overview of the proposed approach.
The paired T-Test used contains several tests for data analysis.Two tests were chosen.These two tests are Equal-Variance-Test and Unequal-Variance T-Test.The focus was on Unequal-Variance T-Test to prove the assumption, as it is the most common type of T-tests and the most used tests that cover large part in statistical test or hypothetical tests.

TABLE II .
SAMPLE SITUATION 1 FROM TABLE I AND ACTIVITY W-V

TABLE V
than once is found in the same case, the average is calculated as the effective time for the activity.For example, in TableVIII, activity "W − Completeren aanvraag" is executed by the resource 11119 more than once in the case 205721, and the effective time for the activity "W − Completeren aanvraag" by the resource 11119 is (0, 19) respectively.The average time is (0 + 19/2 = 9.5).The same is applied for all the cases in the event log.Finally, TableIXillustrates the final result of the preprocessing steps. more

TABLE IX .
SAMPLE OF THE FINAL EVENT LOG FOR OUR APPROACH

Table X
presents some comparative examples before and after implementing the approach.It compares the original log (i.e., test set) and the output of the proposed resource rec-

TABLE X .
SOME COMPARATIVE EXAMPLES BEFORE AND AFTER IMPLEMENTING OF OUR APPROACH Table XI summarizes the results of applying (2) on synthesized and real life logs.It shows resources recommendation based on the average time, the minimum time, and the maximum time to execute each activity in each case over all the log.

TABLE XII .
RESULTS OF APPLYING THE PROPOSED APPROACH ON REAL AND SYNTHESIZED EVENT LOGS