Business Models Enhancement through Discovery of Roles Andrea Burattin University of Padua, Italy Alessandro Sperduti University of Padua, Italy Marco Veluscek Siav S.p.A., Rubano, Italy April 17, 2013

2 of 17 Beyond Process Discovery Image source: Christian W. Gűnther. Process mining in Flexible Environments. PhD thesis, Technische Universiteit Eindhoven, Eindhoven, 2009 .

3 of 17 How to Extend a Model: Perspectives  Typical perspectives of process models – Control-flow perspective ● Identification of the ordering of activities to find a good characterization of all possible paths – Organizational perspective ● Actors and originators involved to classify people or to analyse their social network – Case perspective ● Identification of the properties (i.e., data values) of specific cases – Time perspective ● Timing and frequencies analysis of events

4 of 17 Organizational Mining  Organizational model mining – Find groups of users with similar characteristics according to ● Similarity of performed activities (task based) ● Working on the same process instance (case based)  Social network analysis – Discover how the work is handled between different originators (according to different metrics)  Information flows between organizational entities – Identification of organizational entities by aggregating social network nodes

5 of 17 Model Extension and Roles Discovery  Our aim is to partition the activities of a business process in roles with information from an event log – Transform this – Into this + Instance i 1 A u1 2 B u2 3 C u2 4 D u1 5 E u1 … Instance j 1 A u1 2 B u2 3 C u2 4 D u1 5 E u1 Role A Role B

6 of 17 Basic Assumption of Our Approach  Roles are defined as skills required to perform an activity – Originators characterized by their skills  Assumption we made: the sets of originators of each role are mostly disjoint … reasonable assumption (e.g., production vs management) Performers - User 1 - User 2 - User 3 Performers - User 4 - User 5 Role A Role B

7 of 17 Formal Idea of Our Approach  Given the set of activities A of a process – Find the partition R ⊂ (A) s.t. each activity belongs to one role (we use “role” and “partition of activity” as synonyms) – No “semantic” information associated to roles ● Unless we have information on the skills  Our task as a “clustering problem” – Group elements according to shared features. Rationale is ● High intra-cluster similarity ● Low inter-cluster similarity – The shared features are the activity originators (and the number of times they are observed in the log)

8 of 17 Formal Idea of Our Approach – 2  Basic concept: handover of roles – We have handover of roles when the work moves from two activities belonging to different roles – Example of target partition ● Handover of roles between: a → b a → c b → d c → d  Identification of roles from detection of handover of roles

9 of 17 Identification of Handover of Roles  Check all the dependencies of our process and verify if there is handover of role  Given a dependency a → b, and a log L we calculate – Multiset with all couples of originators of the dependency a → b – Sets and with originators of a and b  There is not handover if – In L, there are traces in which a and b are performed by the same originator (strong no handover) – The set of originators and are equal (no handover)

10 of 17 Identification of Handover of Roles – 2  But we have to cope with noisy and unclear situation  Some more definitions – originators performing a (as part of a → b) – couples of executions of a → b performed by the same originator  Given a dependency a → b, and a log L the measure of no handover between a and b is defined as No handover rule Strong no handover rule

11 of 17 Examples of Computed Values  Example 1 – No handover – Strong no handover – wab = (3 + 6) / (3 + 3) = 1  Example 2 – Partial no handover – Partial strong no handover – wab = (2 + 1) / (3 + 3) = 0.5

12 of 17 Identification of Handover of Roles – 3  We can assign weights (i.e. degree of no handover) to all the dependencies of our model  We “remove” dependencies with weight below a given threshold τw

13 of 17 Identification of Handover of Roles – 4  Resulting connected components may need to be merged into the same role  Given two components Ri and Rj we calculate  If this measure is above the threshold τρ then we can merge Ri and Rj vs

14 of 17 Configuration of τw and τρ  This approach, however, requires two thresholds – τw to split candidate handover of roles – τρ threshold to merge temporary roles  Parameters are thresholds on values coming from a finite log, therefore only a finite number of significant thresholds exists – We can discretize the values of the thresholds – We can compute all significant partitions  We propose an entropy-based measure to define a ranking of the partitions

15 of 17 Entropy-based Measure for Ranking  To compute the entropy measure of the set of roles , given the log L we need – no. times user u is involved in activities belonging to R – no. times user u is involved in any activity  The entropy-based measure is defined as  Clearly reflects our basic assumption – Value 0 if each originator involved in one role

16 of 17 Experimental Setup and Results  Artificial datasets, different configurations – Model 1: 13 activities (AND, XOR), 3 roles – Model 2: 9 activities (AND, XOR, loops), 4 roles  Artificial datasets because we want to know the “correct” partition  Target partition always discovered Log # partitions Rank target partition Model 1 1 user per role 6 1 2 users per role 34 1 2 users per role – 1 jolly 36 4 3 users with leader 31 4 6 users with leader 36 12 Model 2 1 user per role 3 1 2 users per role 12 1 8 users with leader 9 5

17 of 17 Conclusions and Future Work  We presented an approach to extend a control-flow model with an additional perspective (organizational)  Basic procedure – Identification of handover of roles – Merge of candidate roles – Discretization of parameter values and solutions ranking  Possible future work – Improvement of the entropy measure – Deeper experimental analysis for measures validation (and possible tuning)