Sketching Process Models by Mining Participant Stories

Sketching Process Models by Mining Participant Stories Ana Ivanchikj and Cesare Pautasso Software Institute, USI, Lugano, Switzerland [email protected] Abstract. Producing initial process models currently requires gathering knowledge from multiple process participants and using modeling tools to produce a visual representation. With traditional tools this can require significant effort and thus delay the feedback cycle where the initial model is validated and refined based on participants' feedback. In this paper we propose a novel approach for process model sketching by applying existing process mining techniques to a sample process log obtained directly from the process participants. To that end, we spec- ify a simple natural language-like domain-specific language to represent process traces or fragments of process traces. We also illustrate the architecture of a live modeling tool, the Sketch Miner, implementing the proposed approach. The tool produces a draft visual representation of the control flow which is updated in real-time as the traces are written down. The draft model generated by the tool can later be refined and completed by the business analysts using traditional tools. Keywords: Draft Process Model · Process Mining · Process Require- ments · Textual Modelling DSL 1 Introduction One of the identified challenges of business process management in a recent survey is the involvement of people with different skills and background [1], such as process participants with business domain knowledge, the business analysts with process modelling knowledge, and the software engineers with IT background. In the requirements gathering phase for the implementation of a new process in Process Aware Information Systems (PAIS), or when trying to model/improve existing processes, the people with detailed knowledge about the AS-IS or TO- BE business process are the participants in the process. Although they have deep knowledge about the activities that they perform [15], they might lack global knowledge about the end-to-end process [3]. Furthermore, abstracting from the process instances and thinking on the process model level is not always straight- forward, especially for people with little or no modelling experience. Drafting a model of the process with traditional modelling techniques, requires a dedicated person to step in the role of a business analyst, gather the process knowledge from different participants and use a graphical editor to man- ually create the initial draft process model. This requires time and significant 2 A. Ivanchikj et al. cognitive effort by the business analyst, thus causing a delay in obtaining feedback on the draft model by the actual process participants. A comparative study by Damij [5] has shown that the process participant's role when using flowchart- ing modeling techniques, boils down to observation. While when using more natural language like techniques, such as activity tables, the process participants are actively involved to ensure that their activities are correctly captured in the model. On the same note, the study by Ottensooser et.al. [18] has shown that people with no formal training in business process modeling, understand better textual notations describing business processes, such as written use-cases. How- ever, their understanding of the described business process increases by reading a BPMN diagram after having read the written use-cases. To summarize, the existing state of the art process modelling techniques do not empower nor motivate process participants to become directly involved in the initial drafting of the process model. Their only possible involvement is during the interviews with the business analyst, who is then responsible for abstracting the concepts and creating the general picture, which might not align with the reality. However, a potential misalignment will only be discovered after the first draft of the model is finished by the business analyst and shown to the participants, thus creating delays in the feedback cycle. With the work presented in this paper we would like to get the process participants to become actively involved in drafting the model, thus speeding up the feedback cycle. To that end, we propose a simple Domain Specific Language (DSL) that would allow process participants to describe their user stories in a predefined textual format, similar to task lists written in natural language. By transforming these lists into a process log we leverage on existing process mining algorithms to discover the process described by the participants. This Model Sketching by Mining approach allows the mining algorithm to use the unified knowledge of different participants to deduce the control flow branches and to infer the presence of loops, and thus output in real-time an initial draft of the business process in the visual language of choice. The role of the cre- ator of the initial draft model is transferred from the business analysts to the mining algorithm, while the business analyst steps in later, in the refinement and finalization of the model, which can be done with the traditional modeling tools. This does not mean that the business analyst cannot use the DSL to \take notes" and sketch the model while interviewing process participants. That types of involvement allow for a quick initial draft of the process model which can be used to facilitate the discussion and the validation of the model with the stakeholders. While traditionally process mining has been used for discovery of existing processes based on system logs [22], we propose to extend the use of existing mining algorithms to sketch processes out of possible user scenarios or hypothetical participant stories. This paper is structured as follows. In Sec. 2 we discuss briefly the existing textual notations for modelling business processes and motivate the need of defining our own DSL for capturing process knowledge, which we present in Sec. 3. In Sec. 4 we describe the architecture of the Sketch Miner, the proof Sketching Process Models by Mining Participant Stories 3 of concept tool for Model Sketching by Mining, which translates the DSL into complete process traces to be used as input to a mining algorithm. To show the use of the DSL and the tool, in Sec. 5 we model a travel reimbursement process, which we refer to when discussing the benefits and the limitations of our approach in Sec. 6. In Sec. 7 we discuss the related work, while in Sec. 8 we conclude the paper and present work that we plan to conduct in the future. 2 Textual Notations for Process Modeling Using textual notations to generate visual models has been gaining on impor- tance in the modelling languages that target primarily developers. For instance, in Ballerina1, a programming language aimed at the implementation of microser- vices and API integration, the textual and the visual syntax are kept synchro- nized as they are being edited independently. There are also tools, such as Plan- tUML, which support textual modeling of many of the Unified Modeling Lan- guage (UML) visual diagrams which are aimed at documenting software systems artifacts. One of these UML diagrams, the Activity diagram, is intended as a graphical representation of workflows and as such can be used to model business processes. It can be modelled graphically with tools such as StarUML2, but it can also be modelled textually with tools such as PlantUML3, following the syntax rules for distinguishing between different diagram constructs. The syntax uses: 1) keywords, such as \start" and \stop" to denote the beginning and end of a diagram, \if", \then", \else", \elseif" for conditionals, \repeat", \while" for loops, or 2) punctuation signs, such as \:" to denote an activity, \()" to denote a gateway, \| |" to denote swimlanes etc. A survey of textual notations for UML is available in [19]. In the domain of process modelling, the Business Process Execution Lan- guage (BPEL) is a textual XML based language for specifying process behaviour with no standard graphical visual notation4. It uses nesting of constructs to represent the control flow, using keywords to distinguish among different control structures such as <sequence>, <flow>, <if> etc. The target audience of this language are developers. Nitzsche et.al. [17] have proposed BP ELlight to describe interactions only as message exchanges, regardless of the interface defi- nition, thus separating the business logic from the technical protocols and mes- saging infrastructure. BP ELlight extends BPEL with the <conversation> and <interactionActivity> elements which group the interaction activities and thus simplify the original BPEL language, facilitating the modelling of business processes at a more abstract level. However, also BP ELlight does not provide a visual rendering of the process model. 1 https://ballerina.io 2 http://staruml.io 3 http://plantuml.com/activity-diagram-beta 4 https://www.oasis-open.org/committees/download.php/23964/wsbpel-v2.0- primer.htm 4 A. Ivanchikj et al. The Business Process Model and Notation (BPMN) is a standard process modelling language, designed starting from a visual syntax and later enhanced with an XML-based serialization. Recently a textual representation of BPMN has been proposed in plantBPMN [11]. Its target audience are developers, and potentially business analysts, and thus it supports a large number of BPMN constructs. It requires knowledge of BPMN terminology as specific keywords are used for all the node constructs such as \pool", \start", \start timer", \split", \task" etc. It also includes symbols that mimic the graphical constructs, such as the \->" for denoting the sequence flow. The above mentioned DSLs require the users to learn and remember a syntax with different constructs, or rules for expressing different visualizations. As these rules are often similar to expressions used in programming languages, they might be intuitive for developers, but not necessarily for our primary target audience, i.e., process participants. The process participants would use the DSL for model sketching by mining only when mapping their everyday activities to a process, which is expected to happen rarely in their career.

Load more