ROADMAP: A NOVEL METHOD FOR ROLE-BASED AND

Transcription

ROADMAP: A NOVEL METHOD FOR ROLE-BASED AND DECENTRALIZEDPROCESS MODELINGA THESIS SUBMITTED TOTHE GRADUATE SCHOOL OF INFORMATICSOFMIDDLE EAST TECHNICAL UNIVERSITYALİ MERT ERTUĞRULIN PARTIAL FULFILLMENT OF THE REQUIREMENTSFORTHE DEGREE OF MASTER OF SCIENCEININFORMATION SYSTEMSAUGUST 2015

ROADMap: A NOVEL METHOD FOR ROLE-BASED AND DECENTRALIZEDPROCESS MODELINGSubmitted by ALİ MERT ERTUĞRUL in partial fulfillment of the requirements for the degree of Master of Science in Information Systems Department, Middle East TechnicalUniversity by,Prof. Dr. Nazife BaykalDirector, Informatics InstituteProf. Dr. Yasemin Yardımcı ÇetinHead of Department, Information SystemsProf. Dr. Onur DemirörsSupervisor, Information Systems, METUExamining Committee Members:Assoc. Prof. Dr. Aysu Betin CanInformation Systems, METUProf. Dr. Onur DemirörsInformation Systems, METUAssist. Prof. Dr. Sadık EşmelioğluComputer Engineering, Çankaya UniversityAssoc. Prof. Dr. Banu Günel KılıçInformation Systems, METUAssoc. Prof. Dr. Altan KoçyiğitInformation Systems, METUDate:24.08.2015

I hereby declare that all information in this document has been obtained and presentedin accordance with academic rules and ethical conduct. I also declare that, as requiredby these rules and conduct, I have fully cited and referenced all material and results thatare not original to this work.Name, Last Name:Signatureiii:Ali Mert Ertuğrul

ABSTRACTROADMap: A NOVEL METHOD FOR ROLE-BASED AND DECENTRALIZEDPROCESS MODELINGErtuğrul, Ali MertM.S., Department of Information SystemsSupervisor: Prof. Dr. Onur DemirörsAugust 2015, 88 pagesRole-based and decentralized process modeling allows actors to focus on modeling their ownrole behaviors and requires them to communicate and negotiate with each other in order toform a consistent and integrated process model. Due to the collaborative nature of role-basedand decentralized process modeling, negotiations among the actors who play different roleshave a crucial impact on modeling activity of overall process. Based on the communication and negotiation time among the actors, these types of process modeling approaches vary.In this study, we propose a role-based and decentralized process modeling method, calledROADMap, that keeps the strengths and improves the weaknesses of current ones. The exploratory study results reflect that these strengths and weaknesses can be categorized underfive aspects namely flexibility, conflict prevention, information awareness, overall view andlatency. The proposed ROADMap method considers these aspects and it is supported with aweb and cloud-based tool and a notation. A multiple case study is conducted in order to validate the proposed ROADMap method. Case study results indicate that ROADMap method isa successful role-based and decentralized process modeling method for process stakeholdersin organizations.Keywords: Role-based Process Modeling, Decentralized Process Modeling, ColaborativeProcess Modelingiv

ÖZROADMap: ROL TABANLI VE DAĞITIK SÜREÇ MODELLEME İÇİN YENİ BİRYÖNTEMErtuğrul, Ali MertYüksek Lisans, Bilişim SistemleriTez Yöneticisi: Prof. Dr. Onur DemirörsAğustos 2015 , 88 sayfaRol tabanlı ve dağıtık süreç modelleme aktörlerin kendi rol davranışlarını modellemeye odaklanmalarını sağlar ve tutarlı ve bütünleşmiş bir süreç modeli oluşturmak için onların birbirleriile iletişimlerini ve müzakere etmelerini gerektirir. Rol tabanlı ve dağıtık süreç modellemenin işbirlikçi doğası gereği, farklı rolleri icra eden aktörlerin arasındaki müzakerelerin tümsüreci modelleme faaliyeti üzerinde önemli bir etkisi vardır. Aktörler arasındaki iletişim vemüzakere zamanına göre, bu tür süreç modelleme yaklaşımları değişiklik gösterir. Bu çalışmada, mevcut rol tabanlı ve dağıtık süreç modelleme yöntemlerinin güçlü yönlerini içeren vezayıf noklarını geliştiren ROADMap yöntemi önerilmektedir. Açınsayıcı çalışma, bu güçlüyönlerin ve zayıf noktaların esneklik, çakışma önleme, bilgi farkındalığı, genel görünüm vegecikme olmak üzere beş kategori altında toplanabileceğini göstermektedir. Önerilen ROADMap yöntemi bu noktaları göz önünde bulundurmaktadır ve web ve bulut tabanlı bir araç ve birnotasyon tarafından desteklenmektedir. Önerilen ROADMap yöntemini doğrulamak amacıylabir çoklu durum çalışması gerçekleştirilmiştir. Durum çalışması sonuçları göstermektedir kiROADMap yöntemi kurumlardaki süreç paydaşları için başarılı bir rol tabanlı ve dağıtık süreçmodelleme yöntemidir.Anahtar Kelimeler: Rol Tabanlı Süreç Modelleme, Dağıtık Süreç Modelleme, İşbirlikçi SüreçModellemev

To all belovedvi

ACKNOWLEDGMENTSI would like to express my sincere appreciation to my advisor, Prof. Dr. Onur Demirörs forhis guidance, continuous support, encouragement and valuable suggestions throughout theresearch. He was the source of inspiration for me with his extensive knowledge and creativethinking.I appreciate the feedback offered by my thesis committee members Assoc. Prof. Dr. AysuBetin Can, Assoc. Prof. Dr. Altan Koçyiğit, Assist. Prof. Dr. Sadık Eşmelioğlu and Assoc.Prof. Dr. Banu Günel Kılıç.I wish to offer my special thanks to my friends Serhat Peker, Emre Sezgin and Şeyma Çavdarfor their motivation and insightful discussions. I also thank them for their patience and helpduring the case studies. I owe special thanks to my friends Mahir Kaya, Özge Gürbüz andNuray Baltacı for their kind friendship.I would like to thank Murat Salmanoğlu, Ahmet Coşkunçay and Ali Yıldız for their contributions to the case studies.I sincerely thank my mother Fulya, my father Dursun and my lovely, little sister Naz for theirencouragement and motivation during my whole life. This thesis would not be accomplishedwithout their endless support.Last but not the least, my most sincere and intimate appreciation is reserved for my dearie andbeautiful fiance Itır for her never-ending love, support, motivation and illuminating thoughtsduring every moment of my life. I am very lucky to grow old together with her so that we willboth enjoy to discover the world together and feel the peace at home.vii

TABLE OF CONTENTSABSTRACT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .ivÖZ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .vACKNOWLEDGMENTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .viiTABLE OF CONTENTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viiiLIST OF TABLES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .xiiLIST OF FIGURES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xivCHAPTERS12INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11.1The Problem Statement . . . . . . . . . . . . . . . . . . . . . . . .21.2The Solution Approach . . . . . . . . . . . . . . . . . . . . . . . .31.3Research Questions . . . . . . . . . . . . . . . . . . . . . . . . . .41.4Organization of the Thesis . . . . . . . . . . . . . . . . . . . . . . .4LITERATURE REVIEW . . . . . . . . . . . . . . . . . . . . . . . . . . . .72.1Collaborative Process Modeling Tools . . . . . . . . . . . . . . . .72.2Decentralized Process Modeling Approaches . . . . . . . . . . . . .92.3Process Modeling Notations for Role-based Modeling . . . . . . . .132.3.1Business Process Model and Notation . . . . . . . . . . .132.3.2Role Activity Diagram . . . . . . . . . . . . . . . . . . .15viii

2.3.3Subject-oriented Business Process Management Notation .16Discussion on Literature Review . . . . . . . . . . . . . . . . . . .20ROADMAP METHOD . . . . . . . . . . . . . . . . . . . . . . . . . . . . .213.1Process of Method Application . . . . . . . . . . . . . . . . . . . .213.1.1Preparation Phase . . . . . . . . . . . . . . . . . . . . . .213.1.2Modeling Phase . . . . . . . . . . . . . . . . . . . . . . .223.1.2.1Flexibility . . . . . . . . . . . . . . . . . . .223.1.3Conflict Prevention . . . . . . . . . . . . . . . . . . . . .233.1.4Information Awareness . . . . . . . . . . . . . . . . . . .233.1.5Overall View . . . . . . . . . . . . . . . . . . . . . . . .233.1.6Latency . . . . . . . . . . . . . . . . . . . . . . . . . . .243.2The Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .243.3The Tool Support . . . . . . . . . . . . . . . . . . . . . . . . . . .273.3.1Architecture of the Tool . . . . . . . . . . . . . . . . . .273.3.2Requirements of the Tool . . . . . . . . . . . . . . . . . .283.3.2.1General Modeling Requirements . . . . . . .293.3.2.2Method Specific Requirements . . . . . . . .30An Example Utilization of the Tool . . . . . . . . . . . .32EXPLORATORY AND MULTIPLE CASE STUDIES . . . . . . . . . . . .394.1Exploratory Study . . . . . . . . . . . . . . . . . . . . . . . . . . .394.1.1Analysis of Current Approaches . . . . . . . . . . . . . .394.1.1.1Ex-ante Communication Negotiation . . . . .414.1.1.2Ex-post Communication Negotiation . . . . .422.433.3.34ix

4.1.1.3Ongoing Communication Negotiation . . . .44Discussion . . . . . . . . . . . . . . . . . . . . . . . . .45Case Studies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .474.2.1Research Questions . . . . . . . . . . . . . . . . . . . . .484.2.2Multiple Case Study Design . . . . . . . . . . . . . . . .484.2.2.1Selection of the Cases . . . . . . . . . . . . .484.2.2.2Data Collection . . . . . . . . . . . . . . . .494.2.2.3Data Analysis . . . . . . . . . . . . . . . . .50Case Study Conduct . . . . . . . . . . . . . . . . . . . .504.2.3.1Case Study 1 . . . . . . . . . . . . . . . . . .514.2.3.2Case Study 2 . . . . . . . . . . . . . . . . . .52Threats To Validity . . . . . . . . . . . . . . . . . . . . .53RESULTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .555.1Case Study 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .555.2Case Study 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .585.3Discussion on Case Study Results . . . . . . . . . . . . . . . . . . .61CONCLUSION AND FUTURE WORK . . . . . . . . . . . . . . . . . . . .656.1Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .656.2Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .67REFERENCES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .694.1.24.24.2.34.2.456APPENDICESAADMINISTRATOR COMPONENT SCREEN SHOTS . . . . . . . . . . . .x75

BCDPROCESSES MODELED IN CASES . . . . . . . . . . . . . . . . . . . . .77B.1IS100 Examination Process . . . . . . . . . . . . . . . . . . . . . .77B.2Training Process . . . . . . . . . . . . . . . . . . . . . . . . . . . .77PROCESS MODELS FORMED DURING CASE STUDIES . . . . . . . . .79C.1IS100 Examination Process . . . . . . . . . . . . . . . . . . . . . .79C.2Training Process . . . . . . . . . . . . . . . . . . . . . . . . . . . .82INTERVIEW QUESTIONS . . . . . . . . . . . . . . . . . . . . . . . . . .87xi

LIST OF TABLESTABLESTable 2.1 Comparison of Current Collaborative Process Modeling Tools . . . . . . .9Table 2.2 The core elements of BMPN . . . . . . . . . . . . . . . . . . . . . . . . .14Table 2.3 The elements of RAD . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16Table 2.4 The elements of S-BPM notation . . . . . . . . . . . . . . . . . . . . . . .18Table 3.1 Truth Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25Table 3.2 The core elements of the notation that ROADMap method supports . . . . .26Table 3.3 Requirement 1.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29Table 3.4 Requirement 1.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29Table 3.5 Requirement 1.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29Table 3.6 Requirement 1.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30Table 3.7 Requirement 1.5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30Table 3.8 Requirement 2.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30Table 3.9 Requirement 2.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31Table 3.10 Requirement 2.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31Table 3.11 Requirement 2.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31Table 3.12 Requirement 2.5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32xii

Table 3.13 Requirement 2.6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32Table 4.1 Comparison of Current Role-based Process Modeling Approaches . . . . .46xiii

LIST OF FIGURESFIGURESFigure 2.1 The Plural Phases [69] . . . . . . . . . . . . . . . . . . . . . . . . . . . .11Figure 2.2 The overview of Comprehand [70] . . . . . . . . . . . . . . . . . . . . . .13Figure 2.3 Process Model of Business Trip Application Process using BPMN 2.0 . . .15Figure 2.4 Process Model of Business Trip Application Process using RAD . . . . . .17Figure 2.5 Subject Interaction Diagram of Business Trip Application Process . . . . .19Figure 2.6 Subject Behavior Diagrams of Business Trip Application Process . . . . .19(a)Employee SBD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19(b)Manager SBD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19(c)Travel Office SBD . . . . . . . . . . . . . . . . . . . . . . . . . . . .19Figure 3.1 Preparation Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22Figure 3.2 Logical Operators in Extended S-BPM Notation . . . . . . . . . . . . . .27Figure 3.3 Basic Architecture of a Cloud-based System . . . . . . . . . . . . . . . .27Figure 3.4 High Level System Architecture of Tool Support . . . . . . . . . . . . . .28Figure 3.5 Modeling Page of the Modeling Component . . . . . . . . . . . . . . . .33Figure 3.6 Receive Message Popup of Modeling Component . . . . . . . . . . . . . .34Figure 3.7 Definition of a New Message . . . . . . . . . . . . . . . . . . . . . . . .34xiv

Figure 3.8 Notification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34Figure 3.9 Related Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35Figure 3.10 Send Message Popup of Modeling Component . . . . . . . . . . . . . . .35Figure 3.11 Consistency Check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36Figure 3.12 Overall View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37Figure 3.13 Role Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37Figure 4.1 Subject Interaction Diagram of Software Integration Process . . . . . . . .40Figure 5.1 Frequencies of the Answers for Case 1 . . . . . . . . . . . . . . . . . . .57Figure 5.2 Frequencies of the Answers for Case 2 . . . . . . . . . . . . . . . . . . .60Figure 5.3 Frequencies of the Answers for Discussion . . . . . . . . . . . . . . . . .62Figure A.1 Home Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .75Figure A.2 Assign Actor Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .76Figure C.1 Role Behavior Diagram of Administrator . . . . . . . . . . . . . . . . . .79Figure C.2 Role Behavior Diagram of Course Coordinator . . . . . . . . . . . . . . .80Figure C.3 Role Behavior Diagram of Course Assistant . . . . . . . . . . . . . . . . .81Figure C.4 Role Behavior Diagram of Team Leader . . . . . . . . . . . . . . . . . . .82Figure C.5 Role Behavior Diagram of Attendee . . . . . . . . . . . . . . . . . . . . .83Figure C.6 Role Behavior Diagram of Reviewer . . . . . . . . . . . . . . . . . . . .84Figure C.7 Role Behavior Diagram of Trainer . . . . . . . . . . . . . . . . . . . . . .85xv

xvi

CHAPTER 1INTRODUCTIONBusiness process modeling has become an important activity for a growing number of organizations during the last decade. Organizations use business process modeling as a way torepresent the work knowledge [20] [32]. Moreover, it is used in many fields of organizationallife such as explicit definition of processes, process execution and automation, assessmentand identification of added value, comparison of workflows to be planned and realized, software requirements identification and quality manual establishment. Therefore, process models are significant assets for the organizations since they are utilized for different purposes inseveral organizational activities namely business process management, software process improvement, business process re-engineering and workflow management. As a result, processmodeling can be put forth on as a crucial activity for the organizations.Business process modeling can be seen as single person activity or multi person activity [71].For the single person perspective, one person is accountable for all process modeling activities. In other words, that person should have the domain knowledge, create process modeland verify and validate the created model. However, it is not likely that one person can havein-depth domain knowledge about all aspects of the process. On the other hand, for multiperson perspective, a number of people are responsible for process modeling activities. Sincedomain knowledge may be distributed in the organization, capturing this distributed knowledge and turning it into models requires communication, coordination and decision making.This means that business process modeling has a collaborative nature so that multi personperspective should be followed.Traditionally, business process modeling is performed using a top-down and centralized approach. It means that a group of experts apply modeling based on the knowledge gatheredfrom the stakeholders who participate in process executions. However, in today’s world,the process knowledge is distributed among many workers due to globalized business world.Therefore the acquisition of this domain knowledge for the process modeling is conductedby the process engineers via interviews and questionnaires. Since the process knowledge isspread out over the organization, acquisition of the knowledge is time and effort consuming. Therefore, modeling the processes can take months or even years especially for the largeorganizations. As a result, this leads to a disadvantage for the organizations to change andimprove their business processes in order to adopt them to frequently and rapidly changingenvironment.Demirors pointed out that the process stakeholders have much more information about process domain than the process engineers [10]. Therefore, how accurate the process modelrepresents the actual work highly depends on the degree of stakeholder involvement during1

process modeling [10] [69]. If each stakeholder in the organization is responsible for modeling its own contribution to the process, which is decentralized way, as the modeling canbe performed concurrently by the different stakeholders, total time and effort for the processmodeling will decrease significantly. Similarly, Antunes et al. stressed that expert modelersare needed to be avoided during the elicitation of information about work since they may nothave sufficient knowledge about the actual work [1]. Instead, stakeholders who perform theactual work i.e. people who participated in execution of the process should themselves beinvolved in the process modeling.1.1The Problem StatementIn various studies, the importance of the fact that individuals who involve in process executionmodel their own business processes was declared. Also, this was preferred over employingprocess engineers who gather process knowledge from stakeholders and model accordingly.[2] [18] [29]. While some studies [23] [53] support individual involvement during processmodeling with collaboration, only a few of them are role-based. In other words, stakeholdersdeal with the overall view of the whole business process and cannot focus on their individualroles in the organization. Since roles are the smallest units from which the concerns areseparated in a business process,

roadmap: a novel method for role-based and decentralized process modeling a thesis submitted to the graduate school of informatics of middle east technical university al i mert ertu grul in partial fulfillment of the requirements for the degre