Business Models Enhancement through Discovery of Roles

Control flow discovery algorithms are able to reconstruct the workflow of a business process from a log of performed activities. These algorithms, however, do not pay attention to the reconstruction of roles, i.e. they do not group activities according to the skills required to perform them. Information about roles in business processes is commonly considered important and explicitly integrated into the process representation, e.g. as swimlanes in BPMN diagrams. This work proposes an approach to enhance a business process model with information on roles. Specifically, the identification of roles is based on the detection of handover of roles. On the basis of candidates for roles handover, the set of activities is first partitioned and then subsets of activities which are performed by the same originators are merged, so to obtain roles. All significant partitions of activities are automatically generated. Experimental results on several logs show that the set of generated roles is not too large and it always contains the correct definition of roles. We also propose an entropy based measure to rank the candidate roles which returns promising experimental results.

More info: http://andrea.burattin.net/publications/2013-cidm

Transcript

1. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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)