=Paper=
{{Paper
|id=Vol-1371/paper10
|storemode=property
|title=An Optimal Process Model for a Real Time Process
|pdfUrl=https://ceur-ws.org/Vol-1371/paper10.pdf
|volume=Vol-1371
|dblpUrl=https://dblp.org/rec/conf/apn/ThomasVBP15
}}
==An Optimal Process Model for a Real Time Process==
https://ceur-ws.org/Vol-1371/paper10.pdf
An Optimal Process Model for a Real Time
Process
Likewin Thomas∗ , Manoj Kumar M V∗ , Annappa B∗ , and Vishwanath K P†
∗
Department of Computer Science and Engineering
†
Department of Mathematical and Computational Science
National Institute of Technology Karnataka, Surathkal,
Mangalore - 575025
India
{likewinthomas, manojmv}@nitk.ac.in
annappa@ieee.org
shastryvishwanath@gmail.com
http://www.cse.nitk.ac.in
Abstract. Recommending an optimal path of execution and a com-
plete process model for a real time partial trace of large and complex
α
organization is a challenge. The proposed AlfyMiner ( y M iner) does
this recommendation in cross organization process mining technique by
comparing the variants of same process encountered in different organiza-
α
tion. y M iner proposes two novel techniques Process Model Compara-
α α
tor ( y Comp ) and Resource Behaviour Analyser (RBAM iner ). y Comp
identifies Next Probable Activity of the partial trace along with the
complete process model of the partial trace. RBAM iner identifies the
resources preferable for performing Next Probable Activity and analyse
α
their behaviour based on performance, load and queue. y M iner does
this analysis and recommend the best suitable resource for performing
Next Probable Activity and process models for the real time partial trace.
Experiments were conducted on process logs of CoSeLoG Project1 and
72% of accuracy is obtained in identifying and recommending NPA and
the performance of resources were optimized by 59 % by decreasing their
load.
Keywords: Cross Organization Process Mining, Resource Behavior, Best
Resource, Polynomial Regression Model, Resource Performance, Resource
Load, Resource Queue: Average Waiting Time.
1 Introduction
In the current world where the resources are being shared among different or-
ganization through the cloud computing paradigm, most of the organizations
have started to shift towards Shared Business Process Management Infrastruc-
ture (SBPMI). Due to this shift in modelling paradigm, organizations have to
1
http://dx.doi.org/10.4121/uuid:26aba40d-8b2d-435b-b5af-6d4bfbd7a270
117
continuously improve their process [1]. But most of the organizations are still
depending on the external service providers to monitor their business process,
hence the business links are to be established with those external agencies [2].
This issue was well addressed by the Information Technology by developing var-
ious work-flow tools [3] [4] [5] [6]. The challenge here is to extend the service
from boundary of single organization to cross organizations.
Due to data explosion [7] getting insight and performing analysis on the
data to understand their behaviour and discover an optimized process model
is always been a challenge to any organization in the process mining environ-
α
ment. y M iner uses SBPMI, to analyse the data behaviour of an organization.
This is achieved by comparing the model of same variant using RBAM iner in
SBPMI and recommending the best suitable process model. The context of this
paper is the CoSeLoG Project2 . The data used for the experiment and analy-
sis of proposed algorithm is obtained from the Configurable Services for Local
Government (CoSeLoG) Project. This project was executed under Dutch Orga-
nization for Scientific Research (NWO) [8].
αy M iner is a new analytical tool for discovering the optimal path of com-
pletion of a partial trace along with recommendation of complete process model.
It proposes two novel techniques α y Comp and RBAM iner . α y Comp identifies
the optimal path of completion by matching the partial trace and discovering
the variants in all process models logged in the repository. It identify and recom-
mends the Next Probable Activity (NPA) of partial trace. RBAM iner identifies
the suitable resource for performing the discovered NPA, by analysing the be-
haviour of all resources capable of performing NPA based on their performance,
load and waiting time.
α y M iner is analysed using the running example [2]. NPA for the partial
trace and optimal process model is identified in cross organization environment
α
using y Comp [3] and the resource preferable for performing NPA is analysed
and recommended using RBAM iner [4]. The experiment is conducted using the
real time event log of CoSeLoG Project3 and the result of RBAM iner is presented
in section [5].
2 Running Example
α
The proposed y M iner is illustrated using the running example of four variant
process model containing 9 activities, shown in Figure[1b]. The corresponding
sample event log describing the process execution of the process model is shown
in Table[1]. Here the traces matches model perfectly which is not the cases in
real life process model. The complete log file of the running example can be
2
http://dx.doi.org/10.4121/uuid:26aba40d-8b2d-435b-b5af-6d4bfbd7a270
3
http://dx.doi.org/10.4121/uuid:26aba40d-8b2d-435b-b5af-6d4bfbd7a270
118
found at Process Mining @ NITK 4 . The experimental results are obtained using
the CoSeLoG Project5 .
2.1 Proposed Problem
Consider an online process shown in Figure[1a], the dotted line shows the path
of execution of the online process. Sub-scripted values at each activities are the
sequence of occurrence of the activities ( A1 → B2 → C3 ). At activity C 3 ,
decision has to be taken about which next activity to be performed, either D
or E. α
y M iner identify the NPA and recommends the suitable resource for
performing NPA.
29
D 23 G 37 29
D 28 G 20
A 85 B
85 19 80
(1) C 20
51
H A 80 B C 12 16
H
E 35 23
E
23
I 38
Process Model 1 Process Model 2
(2)
42 C 40 26 I 33 28 B 47 50 G 50
29 42
A 56 B 2414 14
E 15 15 H A 10 6
6 26
15
C E 10
6 5
6
36
6
H
D 26 30 G 23 32 39
D 60 I 36
(3) 20 19 15
F F
D (4) E Process Model 3 Process Model 4
(b) Process Models: Four variants of interview pro-
F G H cess (registration (A), validity check (B), document
(Next Probable Activity)
check (C), information check (D), decide (E), interview
(a) Illustration of On- (I), group discussion (G), result (H) and re-initiates
line Process Model (F))
Fig. 1: Running Example
3 Alfy Miner ( αy M iner)
αy M iner is intended to identify and predict the optimal path of execution
along with the complete process model, for a real time process. On identifying
the currently executing activity Ai , αy M iner recommends the optimal path of
completion and the best suitable process model matching the partial trace with
same variant event logs, logged in the process model repository. On identify-
ing the matched variants, the optimal process models are identified by running
α
process model comparator y Comp which matches the partial trace. Recommen-
dation of Next probable Activity NPA is done by selecting NPA (Ai ) in identified
suitable process model. The Algorithm [1] gives the execution steps of y M iner. α
4
http://http://processminingnitk.blogspot.in/2015/03/best-resource-
recommendation-for.html
5
http://dx.doi.org/10.4121/uuid:26aba40d-8b2d-435b-b5af-6d4bfbd7a270
119
Case ID TRACE Duration
10358444 A12350 630640 221210 23640 7560 631250
24/01/14 B28/01/14 C29/01/14 D02/02/14 E15/02/14 H26/02/14 33
12421232 A23640 530640 230410 12350 7716 631250
25/01/14 B26/01/14 C28/01/14 D09/02/14 G13/02/14 H24/02/14 30
12592056 A12350 4503 630450 721560 7560 631250
02/03/14 B12/03/14 C18/03/14 G26/03/14 E27/03/14 H08/04/14 37
12610928 A23640 530640 230410 7560 23640 7716 631250
12/05/14 B17/05/14 C29/05/14 E05/06/14 D16/06/14 G28/06/14 H05/07/14 54
12984815 A12350 630450 221210 12350 721560 7716 631250
16/08/14 B29/08/14 C09/09/14 D16/09/14 G22/09/14 E15/10/14 H27/10/14 72
(a) Event Log of Process Model 1
Case ID TRACE Duration
13945854 A23640 450320 630450 23640 720560 631250
26/01/14 B28/01/14 C31/01/14 D15/02/14 G19/02/14 H26/02/14 31
13968144 A12350 630450 221210 12350 631210 631250
12/02/14 B19/02/14 C22/02/14 E09/03/14 I26/03/14 H28/03/14 44
15073705 A12350 530640 630450 12350 771620 720560 631250
12/04/14 B29/04/14 C02/05/14 D15/05/14 G19/05/14 E26/05/14 H08/06/14 57
16609162 A23640 530640 230410 720560 23640 771620 631250
15/04/14 B19/04/14 C02/05/14 E15/05/14 D16/05/14 G18/05/14 H20/05/14 35
16789201 A12350 630450 221210 23640 721560 771620 641210 631250
19/06/14 B23/06/14 C29/06/14 D15/07/14 G27/07/14 E09/08/14 I16/08/14 H23/08/14 65
(b) Event Log of Process Model 2
Case ID TRACE Duration
16796450 A12350 450320 630450 720560 651210 631250
02/05/14 B23/05/14 C15/06/14 E19/06/14 I09/07/14 H27/07/14 86
23640 450320 221210 720560 720560 630450 221210 720560 651210 631250
17031584 A26/07/14 B15/08/14 C29/08/14 E12/09/14 F28/09−14 B13/10/14 C18/10/14 E22/10/14 I29/10/14 H30/10/14 96
17939005 A12350 630450 630450 720560 720560 450320 23640 720560 720560 631250
05/10/14 B13/10/14 C22/10/14 E29/10/14 F13/11/14 B19/11/14 D02/12/14 E06/12/14 G10/12/14 H24/12/14 80
19472044 A23640 530640 630450 720560 720560 630450 230410 720560 721560 631210 631250
15/12/14 B19/12/14 C28/12/14 E03/01/15 F05/01/15 B16/01/15 C18/01/15 E22/01/15 G23/01/15 I28/01/15 H29/01/15 45
25845687 A23640 530640 630450 720560 721560 631250
12/11/14 B14/12/14 C19/12/14 E22/12/14 G27/12/14 H30/12/14 48
(c) Event Log of Process Model 3
Case ID TRACE Duration
19830478 A12350
02/05/14 B 12350
02/05/14 E12350
02/05/14 G 12350
02/05/14 H 12350
02/05/14 53
19834032 A12350 12350 12350 12350 12350 12350 12350 12350
02/05/14 B02/05/14 E02/05/14 F02/05/14 C02/05/14 E02/05/14 G02/05/14 H02/05/14 52
19836934 A12350 12350 12350 12350 12350 12350 12350 12350 12350
02/05/14 B02/05/14 C02/05/14 E02/05/14 F02/05/14 B02/05/14 E02/05/14 G02/05/14 H02/05/14 59
19838656 A12350 12350 12350 12350 12350 12350 12350 12350 12350
02/05/14 D02/05/14 B02/05/14 E02/05/14 F02/05/14 B02/05/14 E02/05/14 G02/05/14 H02/05/14 37
19844185 A12350
02/05/14 D 12350
02/05/14 C 12350
02/05/14 E12350
02/05/14 F12350
02/05/14 B 12350
02/05/14 E12350
02/05/14 G 12350
02/05/14 H12350
02/05/14 29
(d) Event Log of Process Model 4
Table 1: Event logs of four different process models of interview pro-
cess shown in figure[1b]. Each log table shows Case ID1 , Trace2 and the total
duration3 . Each cell in trace, shows the activity of the trace, Resource (Super-
scripted) and the time of occurrence of that activity (sub-scripted).
Algorithm 1: αy M iner
Input: Partial Real Time Trace
Output: NPA & Process Model
1 Develop Process model repository;
2 repeat
3 MatchV ar ← Call Match Variant(Ai );
4 α α
y Comp ← y Comp(MatchV ar ) ;
5 Set(NPA) ← InOutBinding (C-Net )
6 until for each currently executing activity Ai
3.1 Process Model: Casual Net
αy M iner uses Casual Net: C-Net notation to represent the process model. C-
Net is a six-tuple: {A,D,ai ,ao ,I,O} representation of process model with A:{set
of activities}, D:{Set of Dependencies}, ai :{Set of Start activities}, ao : {Set of
Output activities} , I : {Set of Input Binding} , O: {Set of Output Binding}.
120
C-Net for all the four process model of the running example is shown in Figure 2.
The repository of process model is maintained for analysing process behaviour.
Process Model 1 Process Model 2
A = { A, B, C, D, E, G, H} A = { A, B, C, D, E, G, I, H}
D = {(A,B), (B,C), (C,D), (C,E), (D,G), (G,H), (E,H)} D = {(A,B), (B,C), (C,D), (C,E), (D,G), (E,I), (G,H), (I,H)}
ai = {A} ai = {A}
ao = {H} ao = {H}
I = {I(A):{Null}, I(B):A, I(C):B, I(D):C, I(E):C, I(G):D, I(H):{G,E}} I = {I(A):{Null}, I(B):A, I(C):B, I(D):C, I(E):C, I(G):D, I(H):{G,E}}
O = {O(A): B, O(B):C, O(C):{D,E}, O(D):G, O(G):H, O(E):H, O(H):{Null} O = {O(A): B, O(B):C, O(C):{D,E}, O(D):G, O(G):H, O(I):H, O(H):{Null}
Process Model 3
A = { A, B, C, D, E, F, G, I, H}
D = {(A,B), (B,C), (B,D), (C,E), (D,E), (E,F), (E,I), (E,G), (F,B), (I,H), (G,H)}
ai = {A}
ao = {H}
I = {I(A):{Null}, I(B):{A,F} I(C):B, I(D):B, I(E):{C,D}, I(F):E, I(I):E, I(G):E, I(H):{I,G}}
O = {O(A): B, O(B):{C,D}, O(C):E, O(D):E, O(E):{I,G,F}, O(F):B, O(I):H, O(G):H, O(H):{Null}
Process Model 4
A = { A, B, C, D, E, F, G, I, H}
D = {(A,B), (A,C), (A,D), (B,E), (C,E), (D,E), (E,F), (F,B), (F,C), (F,D), (E,G), (E,I), (G,H), (I,H)}
ai = {A}
ao = {H}
I = {I(A):{Null}, I(B):{A,F}, I(C):{A,F}, I(D):{A,F}, I(E):{B,C,D}, I(F):E, I(G):E, I(I):E, I(H):{G,I}}
O = {O(A): {B,C,D}, O(B):E, O(C):E, O(D):E, O(E):{F,G,I}, O(F):{B,C,D} O(I):H, O(G):H, O(H):{Null}
Fig. 2: C-Net Representation of process Model in Figure 1b
3.2 Matching variants with Path Detector
When an online process is getting executed, identifying to which variant the cur-
rently executing trace belongs is a challenge for y M iner. Algorithm Variant α
M atch [2] identify the path of execution along with the set of possible NPA.
VariantM atch uses the concept of linked list with 2 nodes: CellSN ode and Vari-
ant N ode which are represented as class. Cell N ode = {f rom1 ← {•a}, to2 ← a,
value3 ← {|•a → a|σ}, count4 = |•a → a| ∈ ζ. Variant N ode {*matrix (address of
Cell N ode ), *prev2 *next3 (address of next and previous Cell N ode )}. The Cell N ode
Figure[3a] stores the information of trace A→B→C→E→F→B→D→E→G→H
of process model 2. The value3 field remains 1 till the sequence in trace appears
first time. On identifying the loop, value in value3 filed is updated to 2 as shown
at Cell N ode with memory 500 in Figure[3a]. Value3 field is an array and stores
the value 1,2 to indicate the sequence B→C is appearing second time in the
trace.Count3 is a counter of the sequence appearance in the trace. Variant N ode
Figure[3b] stores the information of all the variants. This is used while compar-
ing the online sequence with the variants. If a variant matches the sequence,
then that variant is retained else it is deleted from the linked list.
3.3 Process Model Comparator ( αy Comp )
αy Comp compares the C-Net of all the variants in cross organization environ-
ment based on following comparison metrics.
1. Process Model Metric: Compare total number of activities, resources, traces
and variants
2. Relation Metric: Compare total number of parallel, serial activities and
loops.
121
10000 10100 10200
050 100 200 300 400 500 600 700 800 900
*Matrix 50 1050 1100
From A B C E F B C E G I Null
*Prev 10000 10100
To B C E F B C E G I H
Value 1 1 1 1 1 1 2 1 2 2 2 2
*Next 10100 10200 Null
First Cell Node Second Cell Node Third Cell Node
Count 1 1 1 1 1 2 2 2 2 2
*Next 100 200 300 400 500 600 700 800 900 Null
(b) Structure of Vari-
(a) Structure of Cell N ode for sequence ant N ode for the set
A→B→C→E→F→B→D→E→G→H of process of Cell N ode of process
model 2 model 2
Fig. 3: Structure of CellN ode and VariantN ode
Algorithm 2: Matching the Variants: V ariantM atch ()
Input: Online process
Output: Matching matrix
1 Match Variant() struct variantN ode ?gvn, ?tempvn; (gvn : address of linked list say
globle Variant Node), Let ?gvn gives address of the double linked list, Initialize all counter
in cellN ode → 0;
2 repeat
3 ?tempvn ← &gvn Get the address of the double linked list;
4 repeat
5 ?tempcn ← &matrix Get the address of the matrix ;
6 tempcn→from = sequence[i] ∧ tempcn→to = sequence[i+1];
7 if not found then Delete current variantN ode from double linked list and go to 5
8 else Increment the member variable count;
9 if count == val[count] (Current and previous check are passed) then Go to
next→variantN ode in the double linked list and go to step 5
10 else Delete the current→variantN ode from the double linked list and go to 5
11 until ?next in double linked list is null
12 until for each activity in online process
13 Remaining variantnode present in tempvn are all matched variant table for the given
sequence.
3. Complexity Metric: Compare total number of split and join.
4. Service Time Metric: Compare the queue time for each activity.
5. Fitness Metric: Running fitness test along with the time of completion and
valid no of sequence in each event log.
Process Model Metric The process model comparison is done based on No
of {Activities, Resources, Traces & Varinats } and is shown in Table 2a.
Relation Metric α
y Comp analysed that if a model has more parallel relation
it performs well when compared to serial relation, at the same time if the loop
is increased the consumption of execution time also increases. Parallel relation
is identified by Equation 4 in Definition 1. Loops are identified by Equation 5.
Definition 1. Log based ordering relation
Let A = [a, b, c, d, e] be the set of activities and let L be the simple event log
122
i.e., L ∈ A ∗ and Let A be ath th
i activity and B be ai+1 then,
˙
DirectlyF ollow(a>L b) ← {iff ∃ trace σ = ht1 , t2 , ..., tn i ∧
i ∈ [1, 2, ....., n − 1] | σ ∈ L,
∧ ti = a, ∧ ti + 1 = b} (1)
˙ (a−→ b) ← {iff a >L b ∧ b ≯L a}
Casuality (2)
L
˙ (a# b) ← {iff a ≯L b ∧ b ≯L a}
U nrelated (3)
L
˙ (ak b) ← {iff a >L b ∧ b >L a}
P arallel (4)
L
Loop(a>˙ L b>L a) ← {iff (ai == ai+2 ) → ai >L ai+1 >L ai+2 } (5)
The Table 2b gives the relation metric of all the four models in running
example.
Complexity Metric Complexity metric identifies the joins and splits in the
process model. Joins and split are identified using the result of output and in-
put binding. Consider the Figure[1b] where for process model 1: O(A)={B}=85
times, similarly the split {CDE} = 20, its means 20 times activity C is 20 times
followed by both D and E, join {GEH} is joined 16 times. Using this information
complexity metric shown in Table[2c] is developed.
Service Time Metric This metric gives the total service time comparison
for an activity in each model. This comparison helps in identifying the model
serving an activity with less service time. The service time is calculated by
Peach cases
i=1 duration(Ai ), where Ai ⊆ A (set of activities). The sample output
in seconds is shown in Table 2d.
Fitness Metric This gives the numbers of traces that can be successfully run
on the model. This is helpful in deciding how efficient the model is, in running
α
the trace. y Comp identifies the model which runs maximum number of traces
with minimum time. Consider the Table 2e.
3.4 Binding Relation
On identifying variants following the partial trace, the NPA of currently execut-
ing activity Ai is identified using binding relation which bind the incoming and
outgoing activity of Ai . Algorithm 3 eplain the concept of binding relation, where
for each trace in a case, if an activity A is followed by B, then A.outbond ← B
∧ B.inbound ← A, i.e., A has out-bounding relationship with B and similarly B
as in-bounding relationship with A
123
No of Activities No of Resources No of Traces No of Variants
PM 1 8 16 90 10
PM 2 8 14 80 13
PM 3 9 14 56 19
PM 4 9 14 86 51
(a) Process Model Metric
No of Dependency No of Parallel No of Loops No of Serial Joins Splits
PM1 7 2 0 5 PM1 19 20
PM2 8 4 0 4 PM2 16 12
PM3 11 2 2 7 PM3 29 29
PM4 14 3 3
PM4 33 28
(b) Relation Metric (c) Complexity Metric
A B C D
PM1 T(PM1) PM2 T(PM2) PM3 T(PM3) PM4 T(PM4)
PM1 3678956 45896374 56987845 1236589 Event Log1 1 56897845 0.9 78456975 0.75 45789647 0.65 56587874
PM2 2598964 56978746 78594785 4589647 Event Log2 0.8 45878123 1 45678412 0.9 78956478 0.95 78945698
PM3 4577896 36987567 23698124 5698347 Event Log3 0.6 45236984 0.75 56898774 1 69875457 1 65327841
Event Log4 0.45 32789564 0.6 68974564 0.75 39845641 1
PM4 1236978 23678945 22456378 4548768
(e) Fitness Metric
(d) Service Time Metric
Table 2: Process Model Comparator ( αy Comp)
Algorithm 3: To calculate Input & Output Binding
1 InOutBinding () Input: Ai , RTrace
Output: Ai .InputBinding , Ai .OutputBinding
2 repeat
3 if (|a >L b|) then
4 a.Outbound ← b ∧ b.Inbound ← a
P
5 |a >L b| = L(σ) × |{1 ≤ i < |σ| | σ(i) = a ∧ σ(i + 1) = b}| [see [7]]
σ∈L
6 until for each sequence in trace σ in event log L
4 Resource Behaviour Analyser (RBAM iner )
αy M iner on discovering suitable process model with NPA identifies the re-
sources preferable for performing NPA. Set of resource preferable for perform-
ing NPA is identified using Activity/Resourcerep [3]. RBAM iner analyse the be-
haviour and recommend the suitable resource for performing NPA. Behaviour of
the resources is analysed based on 3 parameter: Performance, Load and Queue
using polynomial regression model for load and performance [4.2] and Average
Servicing Time at resource using queue model [4.3]. Algorithm 4 explains the
concept of resource behaviour analysis.
4.1 Activity/Resourcerep
αy M iner identifies the list of resources performing an activity in entire process
log along with the time consumed by them for performing that activity. The
Table 3 gives representational view of list of resources performing an activity in
process model 1 along with the time consumed.
124
Algorithm 4: RBAM iner
1 RBA(N P A)()
Input: N P A&BestResActivity
Output: Recommendationof Res(N P A)
2 repeat
3 Load(Res(N P A) ) ←− P oly.Load(Load(Res(N P A) )); [see algo5]
4 P erf (Res(N P A) ) ←− P oly.P erf (Res(N P A) ); [see algo5]
5 AvgW aiting T ime(Res(N P A) ) ←− Queue(Res(N P A) ); [see algo 6]
6 until (for each resource of N P A in BestResActivity Table)
7 Recommend the optimal load, performance and waiting time resource
Activity Res 12350 Res 23640 Res 630450 Res 530640 Res 450320 Res 221210 Res 230410 Res 501 Res 771620 Res 502 Res 771620 Res 721560
A 36.657 45.380 DNP DNP DNP DNP DNP DNP DNP DNP DNP DNP
B DNP DNP 18.473 22.667 9.25 DNP DNP DNP DNP DNP DNP DNP
C DNP 7 24.684 DNP DNP 5.4667 22.294 DNP DNP DNP DNP DNP
D DNP 25.53 DNP DNP DNP DNP DNP 72 11.5 DNP DNP DNP
E DNP 25.531 DNP DNP DNP DNP DNP 62.5 DNP 91 11.5 DNP
G DNP DNP DNP DNP DNP DNP DNP DNP 7 DNP DNP 13.944
Table 3: Activity/Resourcerep of process model 1 of running example
[DNP: Did Not Play ]
4.2 Resource load & performance analyser
The Yerkes-Dodson Law of Arousal, also known as Arousal Theory, states that
by increasing arousal, the workers performance can be improved. However, if the
level of arousal increases too much, performance decreases Figure[4a] [9]. The
RBAM iner identifies the level of arousal : Optimal Load i.e., the maximum load
the resource can handle efficiently, along with its performance using polynomial
regression model. Performance is a ratio of Total time taken by Load. The per-
formance was analysed by increasing the load and observing the time taken.
It was observed that, as the load was increased, the consumption of the time
was decreasing. But at some point there was a drift and the time consumption
started increasing. That drifted point is known as Arousal (optimal load and
performance of the resources). The Algorithm[5] identifies the load ` and perfor-
mance [T otal time ÷ `] for /resource/unit time.
The RBAM iner first filters the unperformed load 1 (an activity with 0 ms)
and residual load 2 (an activities with exceptional duration). Then the actual
load (`) and average time of Service (α) of each worker each month is identi-
fied. Polynomial regression model[5] is applied on this cleaned data. Since the
RBAM iner is intended in identifying the second degree regression model, the
regression model initialize a 3×3 matrix (A) and 3×1 matrix (B) as shown in
figure [4b& 4c]. Then the transpose of matrix A is multiplied with matrix B.
The result obtained is the coefficient of polynomial equation. On applying the
load on an equation the polynomial curve (power curve) is obtained as shown in
figure. On analysing the polynomial curve and applying the Yerkes-Dodson Law
the optimal load and optimal performance of a resource is identified for each
month.
125
Optimal Performance
n n
n
`2
P P
n `
P
α
Perfromance
n n1 n1 n1
A = 1 ` 1 `2 1 `3
P P P
B = 1 (α×`)
P
n n n
n
P 2 P 3 P 4
` ` ` (α×`2 )
P
Optimal Load
1 1 1 1
Load
(a) Yerkes Dodson Law (b) Matrix Table A (c) Matrix Table B
Fig. 4: Structure of Power Curve for identifying the Optimal Load and Per-
formance and the Structure Initial load & performance matrix for running Poly-
nomial Regression Model
Algorithm 5: Resource Second Order Polynomial Regression Model
Input: ` (Total Load) on each resource each month and α (Log(Average Service Time)) for
running the load ` per month
Output: Optimal Load L & Optimal Performance P
1 Let A[3,3] & B[1,3] be 2 initial Matrix as shown in figure[4b & 4c]; k=0;
2 repeat
3 AInverse ←− T ranspose(A, 3); Transpose: Function transposing the matrix ;
Result ←− multiplyM atrices(AInverse , B); multiplyMatrices: Function for
multiplying matrix ;
4 repeat
5 β[i] ←− Result[i][j]; where β= Coefficient of Polynomial Equation
6 until ((i=0 to 3) ∧ j=0)
7 Polynomial Equation : β0 + β1 ` + β2 `2
8 until (for each resource each unit time)
4.3 Activity Servicing Time Model
Along with identification of load and performance of the resource preferable
for performing NPA, RBAM iner also finds the Activity Servicing Time (i.e.,
the average waiting time for an activity to be served by a resource), before
that resource is recommended. Since the interest is in finding the queue at
each resource, RBAM iner uses Single-Server Models (M/M/1):(GD/∞/∞) and
(M/M/1):(GD/N/∞). Here the model (M/M/1):(GD/∞/∞) describe (Arrival1 /
Departure2 / Server3 ):(Queue discipline4 / Max number in Queue5 / Source of
Calling6 ).
Arrival1 (λ) is the rate at which the activities are arrived at each resources
and Departure2 (µ) is the rate at which the arrived activities are served. Since
RBAM iner is intended in identifying the average waiting time at each resource,
the single server model is applied. When data was analyzed for First Come First
Serve FCFS, Last Come First Serve LCFS and Service in Random Order SIRO,
it was understood that arrival of the activity was following General Discipline
GD as its Queue Discipline4 . As the number in queue and source of calling is
not defined RBAM iner marks them as infinity. The average waiting time in the
126
system Ws is identified using Equations [6- 9]. The Algorithm Activity Servicing
Time [6] starts with identifying the arrival rate λ and the servicing rate µ at
each resources.
The λn & µn in generalized model is shown in Equation[6]. The traffic ρ:
number of activities arriving and getting served per unit time is shown in Equa-
tion[7]. Hence the Average waiting time in system Ls is given in Equation[9].
)
λn = λ λ
Where n = 0,1,2.... (6) ρ= (7)
µn = µ µ
Ls ρ
Ws = (8) Ls = (9)
λ 1−ρ
Algorithm 6: To Discover the Activity Servicing Time
Input: Set of resources:<, Trace:=, Duration of service:∂
Output: Arrival λ, Service µ, Traffic ρ, Ls , Ws
1 Let Arrival λ ∈ Load ` discovered on /Resource/month; Service µ ∈ service rate of λ; Π be
No of Days in month
2 if (if ((Π − =.Date) × 24hrs × 60Sec) ≥ =.∂ then Event is executed in same month;
µ(