VisionWaves: Aligning Business Process Management and Performance Management to Achieve Business (Process) Excellence Marc Kerremans m.kerremans@visionwaves.com Abstract. Today’s economic climate means businesses need to be as effective and efficient as possible, and to make the smartest possible decisions. The way to achieve this is by integrating Performance Management (PM) and Business Process Management (BPM) – a combination that is a prerequisite of Intelligent Business Operations. BPM on its own is not enough, omitting the context of processes. By adding PM you can achieve closed loop performance management, where metrics are compared with business objectives and the results fed back to improve processes and decisions. VisionWaves brings a business model driven approach to the table coping with these requirements and allowing Visual and Connected Management. Client experience confirms that PM and BPM are far more powerful when integrated together than individually. 1 Gaining competitive advantage through better processes and decisions and the limits of BPM Given the economic and institutional crises in our globalized economy, the way to compete is to run your business with maximum efficiency and effectiveness, and to make the smartest possible decisions. One of the approaches is to focus on “the integrated business processes and capabilities that together serve customers in ways that are differentiated from competitors and that create the organization’s formula for business success” [1]. Does BPM on its own deliver this right kind of efficiency? Does the balance between efficiency and agility meet business needs? Is the level of intimacy appropriate for every customer? Let’s look at some examples: - A customer delivery process can be very efficient (for example, following a Lean program) – in fact, it may not contain any idle time at all. But efficiency is not always matched with effectiveness. For example, it may be that because of marketing campaigns in some regions, there are configuration problems and stock breakdowns. - By definition, agility can necessitate some inefficiencies. You need more than minimal stock levels to keep a manufacturing conveyor belt running; similarly, economic growth arguably requires some level of frictional unemployment. - A call center representative may be confronted with a demanding customer, and be forced to decide whether to prioritize overall efficiency or service to this one customer. Does the agent mark the customer as a lead, get off the phone, and move on to the next customer, or continue the conversation with this customer and let others wait? An optimized process won’t help the agent decide, unless the process also provides information about the individual customer’s value to the business. 2 Combining BPM and PM To yield the desired competitive advantage, structured interoperability is required across the organization’s entire BPM, PM and application environments. This interoperability must be business-driven, which means that the initiative needs to start from a broader context than the processes themselves: that of the business architecture, business model, or value chain. The alignment of BPM and PM can be seen from two main perspectives: - Injecting PM into business processes to improve decision-making – i.e. taking an inside-out view of the of the decision - Closed loop performance management – i.e. taking an outside-in view of the decision 2.1 Injecting PM into business processes to improve decision-making Business rules are often used to inject PM into BPM and hence provide decision support. This is a valid approach that makes processes more flexible, offers additional analytic capabilities, and hides much of the complexity that is typical of PM. However, rules engines alone are not enough. They cannot cope with the typical scenario of proliferating business models, products, services, channels, customer segments, and value expectations from different stakeholders. Nor do they provide the vital ability to understand changing environments and respond to that understanding, especially when we look at changing sets of goals. By combining PM with the rule-based approach associated with BPM, you can monitor the decision-making process from an analytical perspective and adapt readily to changing goals. Errors in business rules will be detected sooner, and rules can be changed as necessary, either automatically or manually. 2.2 Closed loop performance management Most BPM initiatives capture metrics to assess the efficiency of a process. A few initiatives have shown, though, that more can be done by setting process metrics in the broader context of a value chain or a business model. It then becomes possible to understand the impact of a given process on the overall performance of the business: either on its overall strategic objectives or a specific business campaign. That understanding can lead to better decision-making at an organizational level. The results of performance monitoring become even more valuable if they are used to adjust business processes and objectives. This closed loop performance management often involves human intervention to improve the way decisions are made – for example, the call center agent might be instructed to look at a metric of the customer’s value to the company before deciding how long to spend on the call. 3 The VisionWaves proposition VisionWaves brings a business model driven approach to the table coping with these requirements and allowing visual and connected management. 3.1 Visual Management © 2013 VisionWaves B.V. All rights reserved. Fig. 1. Example of an implemented instance of a business model. Core to the offering is the VisionWaves business model methodology that delivers a visual representation of the coherence and dependencies between the constituents of the business through depicting an easy to understand business model or value creation model. This visual insight that is missing in most alternatives is one of the key differentiators of VisionWaves within the enterprise performance management market. Furthermore this business model is dynamic meaning that it is context aware and is capable to continuously interact with its environment and its users. 3.2 Connected Management VisionWaves delivers full visibility of value creation, performance, processes and risks in integrated, strategically aligned and actionable management cockpits that are role based and that are generated and maintained by the intelligent framework itself. Based on the same underlying data everybody will get a role based portal that reflects actual, executable, connected, and integrated data. 3.3 Model Driven Application Framework VisionWaves starts with the representation of the ‘business model’ including customer value, the different distribution channels through which this value is delivered, products, services, processes, organization, roles, suppliers, contracts and risks. This meta-model is stored into an object repository and therefore delivers a model-driven object model. Next step is the connection of ‘meta’ performance indicators to the elements of the meta-model that are also stored in the same object repository. Furthermore to feed real data into the object repository a meta-data model is configured as well as the (meta) description of how these data are loaded into the same object repository. Finally even the presentation layer (dashboards, cockpits) is created and maintained by the framework. Perhaps the biggest contribution of this model driven application framework is the way it handles changes. When there is a change in the external environment or internal context management objectives, controls and of course reporting has to be realigned. In this model driven approach this can be done by reconfiguring the models or any of the model components in real-time, followed by the immediate adaptation of all related cockpits, dashboards, and reports. 4 Client case study: Bank achieves Operational Intelligence by combining BPM and PM 4.1 Situation after BPM-only Previous BPM initiatives resulted in leaner operations and well-documented processes, but essential business elements were still missing. For example: - The impact of the change on business results or business value was not clear - There was a lack of information to support senior management decisions, and the impact of those decisions on operational execution was hard to establish - There was not enough information about current processes for the COO to know whether a proposed action, such as a new market campaign, was viable in a particular region - Performance at each level of the management hierarchy (COO, value chain owner, process owner, team owner) was measured, but it was not possible to see how one level impacted another 4.2 Results after implementing VisionWaves - All management levels, from COO to operational team leaders, now have performance information about processes, customers, finance and capabilities to support their decisions - The impact of performance at one level on another level can be seen, and there is a daily “performance dialogue” between all hierarchical levels - This makes it possible to work together to achieve corporate objectives - A range of information to support business campaigns is now available – it is easy to assess whether they are viable, and then measure their impact - Through appropriate use of performance feedback, the bank has closed the loop between initiating actions, monitoring performance and taking new actions © 2013 VisionWaves B.V. All rights reserved. Fig. 2. Example of a Process Manager Cockpit. 5 Conclusion Combining BPM and PM allows management and staff to make better and timelier decisions and the organization becomes more efficient and effective. This will help achieving business (process) excellence and is a crucial step for any enterprise with its sights set on Operational Intelligence or Intelligent Business Operations. References 1. Thomas H. Davenport, Jeanne G. Harris, Competing on Analytics, (Harvard Business School Press, 2007), p. 187 CPN Tools 4: A Process Modeling Tool Combining Declarative and Imperative Paradigms Michael Westergaard1,2? and Tijs Slaats3,4?? 1 Department of Mathematics and Computer Science, Eindhoven University of Technology, The Netherlands 2 National Research University Higher School of Economics, Moscow, 101000, Russia 3 IT University of Copenhagen Rued Langgaardsvej 7, 2300 Copenhagen, Denmark 4 Exformatics A/S, Lautrupsgade 13, 2100 Copenhagen, Denmark m.westergaard@tue.nl, tslaats@itu.dk Abstract. CPN Tools is a tool for modeling, simulating, and analyzing colored Petri nets. The latest iteration of the tool, CPN Tools 4, extends this with constraints known from declarative languages such as Declare and DCR Graphs. Furthermore, this version introduces an explicit pro- cess perspective, powerful extensibility allowing third parties to extend the tools capabilities, and a visualization perspective making it possible to make high-level visualizations of executions directly in the tool. In our demonstration, we show how it is possible to create models in- corporating declarative and imperative constructs and how to use these models to generate simulation logs that can be directly imported into ProM. We show off the new process perspective on top of colored Petri nets, exemplify the use of the perspective to generate readable Java code directly from models, and show how the visualization perspective makes it possible to show the formal underlying model alongside an easier-to- grasp for non-experts high-level visualization. Our intended audience comprise current users of CPN Tools interested in recent developments and practitioners interested in colored Petri nets and hybrid models. We expect to tailor each demonstration to the wishes of the audience. Standard imperative languages are suitable for the description of well-structured and well-understood processes. On the other hand, processes that are less well- understood or less well-structured, are often easier modeled using a declarative approach, where instead of specifying the next task to execute, constraints be- tween tasks are described. Popular languages for imperative specifications in- clude BPMN and (colored) Petri nets. Declarative modeling is a more recent ? Support from the Basic Research Program of the National Research University Higher School of Economics is gratefully acknowledged. ?? This research is supported by the Danish Agency for Science, Technology and Inno- vation through an industrial PhD Grant. and less matured approach which has so far not found widespread application in industry yet, however the two declarative languages Declare [6] and DCR Graphs [2, 3] have been studied extensively in academia over the last decade. Declarative languages do not explicitly specify flow of control, but instead spec- ifies constraints between actions; examples of such constraints are init(A), mean- ing that any execution has to start by executing A, and response(A, B), meaning that after executing A, B has to be executed at some point. Other constraints deal with choices and variations of the response constraint. Hybrid modeling. Recently interest has emerged in hybrid approaches, where some aspects of a process are specified directly using imperative constructs and other aspects declaratively. This is useful if part of the process is well-structured and part is more free, or for going from an abstract, little-understood process, often modeled more naturally using declarative constraints, to a more concrete implementation which by nature is often more imperative. One such hybrid approach is implemented in CPN Tools 4 [5, 7]. This approach combines the places and transitions of colored Petri nets with the constraints of the Declare and DCR Graphs languages. Fig. 1 shows an example of a mixed declarative and imperative model. In the upper half of the screen we describe the registration of a patient using an electronic patient record, which is basically form-filling and well- suited for an imperative approach. In the bottom half we describe the treatment of the patient which is strongly knowledge-based, therefore more flexible and hence modeled using a Declarative approach. While these two aspects could have been modelled as separate processes (one imperative and the other declarative), using the hybrid approach allows us to join the two and show how they interact. Initially, only Receive Patient is required due to the declarative constraint init. After executing Disinfect Wound, Stitch Wound has to be executed because of a response between them. Registration and treatment can happen in parallel, but prescription of antibiotics is dependent on the patient data. The model can be extended with time information and exercises to obtain simulation-based performance information. It is also possible to obtain a sim- ulation log from CPN Tools, which can be imported directly into ProM 6.3 for analysis using a known process. CPN Tools also offers state-space analysis for ensuring the absence of errors such as dead-locks in the process. For more information about hybrid modeling, we refer the interested reader to [7]. Domain-specific visualization. While colored Petri net models are graphical, they are also complex to understand for non-experts. Previously, CPN Tools supported visualizations of such models by means of an external tool, but with version 4 such visualizations are internalized, making it possible to show model and visualization side-by-side without requiring external tools. In Fig. 2, we see two simple visualizations of the model from Fig. 1. The sequence diagram (left) shows a single patient interaction and is updated when simulation is conducted. The visualization is driven purely by the model, and as CPN Tools allows users full control over the simulation, can be used to demonstrate complex scenarios in a simple way. The bar chart (Fig. 2 (right)) shows aggregated statistics over multiple simulations. Fig. 1: Overview of CPN Tools with an example hybrid model for a hospital loaded. Process-partitioned colored Petri nets. Colored Petri nets allow modelers a lot of freedom. Most importantly, it is very hard to separate the flow of data Fig. 2: Two visualizations of the simple model from Fig. 1. The model itself is just visible below the visualizations. from the flow of control, which makes models hard to understand and analyze. Workflow Nets solved this problem for standard Petri nets, but some of the re- strictions are too severe for efficient use of the higher-level formalism. Colored Workflow Nets [1] generalize Workflow Nets to colored Petri nets, but impose some restrictions that make models unnatural. Instead, CPN Tools implements Process-partitioned colored Petri nets (PP-CPNs) [4], which allow more flexibil- ity and more natural models. PP-CPNs explicitly separate the flow of control and data, separating places into process places, local and shared places (for data), resource places, and communication (buffer) places. PP-CPNs allow multiple instances of multiple process types to communi- cate, and hence supports an artifact-centric modeling style. Of course, classical Workflow Nets are recognized as PP-CPNs as one would expect. An example PP-CPN model of a simple producer/consumer system can be seen in Fig. 3 (top). Here, we have two kinds of processes communicating over a buffer place; Fig. 3: A colored Petri net model with an explicit process perspective (top) and (some of the) generated Java code from the model (bottom). producers produce items (integers), store them locally, and transmit them. They use a mutex (a single resource) to prevent race conditions. Initially there are two producers. Consumers receive data from producers, store it locally and dispatch depending on the data. An advantage of PP-CPNs is that it is possible to generate them automati- cally from code and to generate running Java code from such models; an example of code generated from the model in Fig. 3 (top) is shown in Fig. 3 (bottom). Maturity, availability, screencast. CPN Tools is a very mature tool and has been in active use for over 10 years. It enjoyed approximately 5500 down- loads in the period May 1, 2012–May 1, 2013. It is used in teaching in sev- eral universities, used by companies, and a large number of case studies in several fields are available from http://cs.au.dk/cpnets/industrial-use/ and on our own homepage we showcase models from industrial case studies at http://cpntools.org/documentation/examples/. We are currently conduct- ing case studies using the new declarative constraints, but these are on-going and not yet ready for publication. The implementation of the Declare language is an optimized version of the Declare tool [6]. CPN Tools is open source and available for free for everybody at http://cpntools.org/. On this page, we also have a comprehensive getting started guide including screencasts for beginners. In the future, we plan to ex- tend CPN Tools with timed and process-aware versions of Declare. References 1. van der Aalst, W.M.P., Jørgensen, J.B., Lassen, K.B.: Let’s Go All the Way: From Requirements Via Colored Workflow Nets to a BPEL Implementation of a New Bank System. In: Proc. of OTM Conferences (1). LNCS, vol. 3760, pp. 22–39. Springer (2005) 2. Hildebrandt, T., Mukkamala, R.R.: Declarative event-based workflow as distributed dynamic condition response graphs. In: Post-proc.of PLACES 2010 (2010) 3. Hildebrandt, T., Mukkamala, R.R., Slaats, T.: Nested dynamic condition response graphs. In: Proc. of Fundamentals of Software Engineering (FSEN) (April 2011) 4. Kristensen, L.M., Westergaard, M.: Automatic Structure-Based Code Generation from Coloured Petri Nets: A Proof of Concept. In: Proc. of FMICS. pp. 215–230. LNCS, Springer (2010) 5. Westergaard, M.: CPN Tools 4: Multi-formalism and Extensibility. In: Proc. of ATPN. LNCS, vol. 7927, pp. 400–409. Springer (2013) 6. Westergaard, M., Maggi, F.M.: Declare: A Tool Suite for Declarative Workflow Modeling and Enactment. In: Business Process Management Demonstration Track (BPMDemos 2011). CEUR Workshop Proceedings, vol. 820. CEUR-WS.org (2011) 7. Westergaard, M., Slaats, T.: Mixing Paradigms for More Comprehensible Models. In: Proc. of BPM. LNCS, vol. 8094. Springer (2013) Enacting Complex Data Dependencies from Activity-Centric Business Process Models Andreas Meyer1 , Luise Pufahl1 , Dirk Fahland2 , and Mathias Weske1 1 Hasso Plattner Institute at the University of Potsdam {Andreas.Meyer,Luise.Pufahl,Mathias.Weske}@hpi.uni-potsdam.de 2 Eindhoven University of Technology d.fahland@tue.nl Abstract. Execution of process models requires a process engine to handle con- trol flow and data dependencies. While control flow is well supported in available activity-oriented process engines, data dependencies have to be specified manually in an error-prone and time-consuming work. In this paper, we present an extension to the process engine Activiti allowing to automatically extract complex data dependencies from process models and to enact the respecting models. We also briefly explain required extensions to BPMN to allow a model-driven approach for data dependency specification easing the process of data modeling. Keywords: Process Modeling, Data Modeling, Process Enactment, BPMN, SQL 1 Introduction Today, organizations use process-oriented systems to automate the enactment of their business processes. Therefore, processes are often captured in process models focusing on the activities being performed. These models are executed by process engines as, for instance, YAWL [1], Activiti [2], jBPM [6], Bonita [3], AristaFlow [8], and Adept2 [13]. Generally, a process engine has access to a process model repository as shown in Fig. 1. As soon as a start event of a particular process occurs, the engine creates a new instance of this process and enacts the control flow as specified by the process model. Thereby, the process engine is able to allocate specified user tasks to process participants via a graphical user interface or to invoke an application for execution of service tasks. For the enactment of tasks, data plays an important role, because data specifies pre- and postconditions of tasks. A precondition requires the availability of certain data in a specified state while the postcondition demands certain manipulation of data. In modern activity-oriented process engines as mentioned above, these and further complex data dependencies (e.g., creating and updating multiplicity relations between data objects) have to be implemented manually through a process engineer by specifying the respective data access statements (see shaded elements in Fig. 1 left); this is an error-prone and time-consuming work. In this paper, we explain an approach to model data dependencies in the process model itself and automatically derive data access statements from the process model as shown in Fig. 1 right. Process data utilized during activity execution is out of scope in this paper. We demonstrate the feasibility of this approach using the industry standard Process Designer Process Participant Process Designer Process Participant Business Process Graphical Invoked Business Process Graphical Invoked Modeling User Interface Applications Process Engineer and Data Modeling User Interface Applications Business Business Process Data access Process Engine Process Model Process Engine Model with Data statements Repository Repository Database Database Fig. 1. Process engine architecture: classical (left) and proposed (right). for process modeling, the Business Process Model and Notation (BPMN) [12], and the Activiti process engine [2]. Next, Section 2 shows how to model complex data dependencies in BPMN; Section 3 shows how three simple conservative extensions of the industrial process engine Activiti suffice to enact complex data dependencies from a BPMN model. We conclude in Section 4. 2 Modeling Complex Data Dependencies in BPMN BPMN provides the concept of data objects that are associated to tasks [12]. Roughly, a task is only enabled when its associated input data objects are in a particular state. Associated output data objects have to be in a specified state when the task completes. However, for enactment more information is required. Figure 2 shows a stan- case object: Order dard BPMN model of a sim- plified build-to-order pro- Order [received] Order [rejected] Order [confirmed] Order [sent] Computer Manufacturer cess of a computer manufac- pk: o_id pk: o_id pk: o_id pk: o_id turer (ignoring annotations Create set in italics). In this pro- Check order component Process order list cess, an Order that was re- ceived from a customer is [new] Components first Checked and either re- [created] III jected or confirmed. If it is pk: cp_id fk: o_id confirmed, task Create com- ponent list creates several Fig. 2. Build-to-order Process of a Computer Manufacturer Components to be ordered; based on these components the order is processed in a subprocess and, when completed, the Order is sent to the customer. In BPMN, each data object has a name and a set of attributes of which one describes the state of a data object. Data flow edges express pre- and postconditions to the different tasks, e.g., Check order is only enabled if object Order exists in state received in the current process instance. However, when handling multiple orders in different instances in parallel, the process model does not express which order is correlated to which process instance. Likewise, BPMN cannot describe create, read, update, and delete operations on one or more objects of the same kind, possibly in 1:n or m:n relationship to other data objects. For instance, one cannot express that task Create component list of Fig. 2 creates several new Component objects and associates them to the Order handled in the process. Such data dependencies would have to be implemented manually. In [9], we have shown that a few simple additional annotations to BPMN data objects suffice to describe such complex data dependencies with operational semantics directly in BPMN. First, borrowing an idea from business artifacts [5], we propose that for each process instance (and each instance of a subprocess) exists exactly one data object instance driving and orchestrating the execution of the process instance. All other data objects used in the instance depend on that case object. The case object of Fig. 2 is an Order as shown by the annotation. Dependencies between data objects are expressed via primary and foreign key attributes in analogy to databases [14]. Each data object has a primary key attribute that uniquely distinguishes different instances of this object, e.g., Order has the primary key attribute o id and Component has cp id. Foreign key attributes link object instances, e.g., attribute o id links Components to Orders. The primary key of the case object implicitly links to the instance identifier of the (sub-)process. Read and update of data objects are already provided through BPMN’s data flow edges. We express create or delete through respective annotations in the BPMN data object, e.g., Create components list creates several new Components (annotation [new] and multi instance characteristic |||) and relates them to the current Order. Most importantly, these annotations have operational semantics. In [9], it is shown how to derive SQL queries from annotated BPMN data objects that realize the specified data operations. For example, for object Order in state rejected written by activity Check order in Fig. 2, the corresponding SQL query is dervied: UPDATE Order SET state = ’rejected’ WHERE o id = $ID with $ID representing the identifier of the (sub-)process the activity belongs to. See [9] for full details. 3 Tool Architecture and Implementation We implemented the approach of Section 2 to show its feasibility. In the spirit of adding only few data annotations to BPMN, we made an existing BPMN process engine data- aware by only few additions to its control structures. As basis, we chose Activiti [2], a Java-based, lightweight, and open source process engine specifically tailored for a subset of BPMN. Activiti enacts process models given in the BPMN XML format. Activiti supports standard BPMN control flow constructs. Data dependencies are not enacted from the process model, but are specified separately. We adapted the Camunda [4] modeler to allow the creation of BPMN models with our proposed concepts; we extended the Activiti engine to enact process models with these concepts. First, we extended the XML specification by utilizing extension elements, which the BPMN specification explicitly supports to add new attributes and properties to existing constructs. We added the case object as additional property to the (sub-)process construct. The data object was extended with additional properties for primary key (exactly one), foreign keys (arbitrary number), and the data access type as attribute. The BPMN parser of Activiti was extended to read BPMN data objects with the new attributes and properties, and data associations. Execution Atomic BPMN DB Server Operation Activity Execute Behavior loop pre [ resultSet.size() == 0 ] SELECT ... FROM PRE WHERE ... BPMN Data Objects resultSet as ... A Control Flow and Resource Activity Behavior UPDATE POST ... post .bpmn file Parser Internal Representation Engine Fig. 3. Data dependencies are a conservative extension to data format, parser, internal representa- tion, and execution engine. The actual execution engine was extended at two points: before invoking the execu- tion of an activity to check the preconditions of an activity and before completing an activity to realize the postconditions, both with respect to data objects. At either point, the engine checks for patterns of data input and output objects and categorizes them. For instance, in Fig. 2, Order is input and output to Check order in different states. The engine classifies this as a “conditional update of case object Order”. The data operations at task Create component list would be classified as “conditional creation of multiple data objects that depend on the case object (1:n relationship)”. Classification proceeds from most specific to most general patterns. When invoking an activity, for each matching precondition pattern a corresponding SQL select query is generated to read whether the required data objects are available. The query assumes that for each data object of the process model exists a table holding all instances of this object and their attributes. If there is an object instance in the right state, the SQL query returns the corresponding entry and is empty otherwise. The engine repeatedly queries the database until an entry is returned (i.e., the task is enabled), as shown in Fig. 3. Then the activity is executed. Upon completion, an SQL insert, update, or delete query is generated for each matching postcondition pattern, and executed on the database. Altogether, we had to extend Activiti at merely 4 points to realize our concept, as illustrated in Fig. 3: (1) at the XML, (2) at the parser and internal representation, (3) when checking for enabling of activities, and (4) when completing an activity. The extensions required just over 1000 lines of code with around 600 lines being concerned with classifying data access patterns, generating, and executing SQL queries. The extended engine, a graphical modeling tool, example process models, a screencast, and a complete setup in a virtual machine are available together with the source code at http://bpt.hpi.uni-potsdam.de/Public/BPMNData. 4 Conclusion In this paper, we presented an approach how to automatically enact complex data dependencies from activity-centric process models. They key concepts required are data objects associated to tasks; a few annotations allow to express relations between data objects and the particular data operation. Our modeling tool helps to easily specify the required annotations in a graphical user interface. From these annotations, SQL queries can be automatically generated and executed from a process engine, covering all fundamental data access operations: create, read, update, and delete of single data objects and of related data objects in 1:n and m:n relationship [9]. We have shown on the process engine Activiti that minimal extensions to existing execution engines suffice to implement this concept. Compared to other techniques and engines for enacting data dependencies from models, our approach is less intrusive. The object-centric modeling paradigm [5, 11] requires substantial changes to the infrastructure as completely new engines have to be used. Process engines for this paradigm exist, e.g., PhilharmonicFlows [7] and Corepro [10], but they are incompatible with activity-centric approaches as it is supported by BPMN. In this respect, our work fills a critical gap in allowing owners of activity- centric processes to adapt automated enactment of data dependencies without changing paradigms and infrastructure. Acknowledgements. We thank Kimon Batoulis, Sebastian Kruse, Thorben Lindhauer, and Thomas Stoff for extending the Camunda modeler [4] in the course of their master project to support the modeling of processes with respect to the concepts described in [9]. References 1. van der Aalst, W.M.P., ter Hofstede, A.H.M.: YAWL: Yet Another Workflow Language. Information Systems 30(4), 245–275 (2005) 2. Activiti: Activiti BPM Platform. https://www.activiti.org/ 3. Bonitasoft: Bonita Process Engine. https://www.bonitasoft.com/ 4. Camunda: Camunda BPM platform. https://www.camunda.org/ 5. Cohn, D., Hull, R.: Business artifacts: A data-centric approach to modeling business operations and processes. IEEE Data Eng. Bull. 32(3), 3–9 (2009) 6. JBoss: jBPM Process Engine. https://www.jboss.org/jbpm/ 7. Künzle, V., Reichert, M.: PHILharmonicFlows: Towards a Framework for Object-aware Process Management. Journal of Software Maintenance and Evolution: Research and Practice 23(4), 205–244 (2011) 8. Lanz, A., Reichert, M., Dadam, P.: Robust and flexible error handling in the aristaflow bpm suite. In: CAiSE Forum 2010. vol. 72, pp. 174–189. Springer (2011) 9. Meyer, A., Pufahl, L., Fahland, D., Weske, M.: Modeling and Enacting Complex Data Dependencies in Business Processes. In: Business Process Management. LNCS, vol. 8094, pp. 171–186. Springer (2013) 10. Müller, D., Reichert, M., Herbst, J.: Data-driven modeling and coordination of large process structures. In: OTM 2007. LNCS, vol. 4803, pp. 131–149. Springer (2007) 11. Nigam, A., Caswell, N.S.: Business artifacts: An approach to operational specification. IBM Systems Journal 42(3), 428–445 (2003) 12. OMG: Business Process Model and Notation (BPMN), Version 2.0 (2011) 13. Reichert, M., Rinderle-Ma, S., Dadam, P.: Flexibility in process-aware information systems. ToPNoC 5460, 115–135 (2009) 14. Silberschatz, A., Korth, H.F., Sudarshan, S.: Database System Concepts, 4th Edition. McGraw- Hill Book Company (2001) An Extensible Platform for Process Model Search and Evaluation Christian Ress and Matthias Kunze Hasso Plattner Institute at the University of Potsdam, christian.ress@student.hpi.uni-potsdam.de, matthias.kunze@hpi.uni-potsdam.de Abstract. We present a platform that integrates a number of process model search techniques and provides a uniform interface for query formulation and search result presentation, as well as a framework to evaluate a particular search technique. The platform provides researchers with a common infrastructure to embed their search technique in form of a dedicated search engine. The demo explains the features of our platform and encourages researchers to contribute their search techniques. 1 Introduction & Background Business process models are a central cornerstone of process-oriented organiza- tions as they explicitly capture the knowledge to carry out the operations of a business and are reused for documentation, analysis, automation, and certifica- tion, among others. Modern companies maintain thousands of process models for reference and reuse [2], which requires effective capabilities to search among them. Researchers have proposed an abundance of techniques that focus on text, structure, or behavior of process models and allow for similarity search, i.e., obtaining approximate matches to a complete model, and querying, i.e., searching precisely by few yet relevant aspects of a model [2]. The majority of these process model search techniques, however, has been presented only theoretically. Evaluations of their quality and performance has been conducted under lab conditions, i.e., with a minimalistic implementation that mainly addresses the query processing, i.e., comparing candidate models with the query and deciding a match. This is, arguably, due to the effort of providing a complete process model search infrastructure that includes a user interface to formulate a query, a process model repository to store, manage, and retrieve models from, and the visual presentation of search results as a response to the query. This functionality is shared among all process models search techniques. To this end, we have developed a prototypical process model search platform that assumes these tasks and allows for the integration of dedicated search techniques in form of a search engine plugin architecture. This includes a set of well-defined APIs that integrate a search engine with our platform. Moreover, the platform provides a framework to evaluate a search engine with regards to the quality of a search technique, i.e., the relevance of the provided results, and, the performance of its implementation. The platform aims to reduce the time to implement and evaluate a particular search technique, and enables the 2 Christian Ress and Matthias Kunze comparison of various techniques, as they can now be deployed in the same runtime environment. 2 Search with your Search Technique The central concept of our search platform is to enable developers to deploy a dedicated search engine to the platform and use it to search for process models in a straight-forward manner. Hence, one of the key features of our search platform is a presentation layer, which lets users specify search queries using BPMN and view ranked search results in a similar visual representation, depicted in Fig. 1. Fig. 1: Screenshot of the web-search interface. The presentation layer includes a simplistic, web-based process model editor, that allows formulating queries as regular process models, as this is typical for similarity search and has been proposed for querying [6], too. The editor itself is highly extendable, which allows the formulation of queries in languages devised for search, e.g., BPMN-Q [1]. The input query is provided to the dedicated search engine that parses it and matches it against stored process models. To this end, BPMN queries are transformed to Petri nets. The extensible architecture of the search platform makes it possible to inte- grate a dedicated search engine, provided it is implemented in Java, by providing common interfaces through which the search platform can communicate with the search engine. Currently, we require that search algorithms accept queries in form of Petri nets, defined using the jBPT Java library1 , and return search results in a similar format. We resorted to Petri nets, as they provide a common formalism for a variety of business process modeling languages [7]. Our aim is to provide researchers with an opportunity to experiment with their algorithms faster and easier, and explore the search results in an environment that is similar to one that end users expect. We do this by providing an API through which search algorithms can expose parameters that can be changed during runtime, and make these parameters accessible in the search interface. This way, parameters can be configured without modifying source code or static configurations, and without recompilation. The results of the chance are visible immediately. 1 http://code.google.com/p/jbpt/ An Extensible Platform for Process Model Search and Evaluation 3 3 Evaluate your Search Technique Our platform has originally been devised to integrate a number of dedicated search techniques in a common infrastructure. However, it turned out that the very same functionality of a search engine can be used to evaluate the underlying search technique and its implementation. That is, experiments are typically carried out by running a well-defined set of queries against a set of candidates, and assessing quality and performance. Thus, we developed a framework that allows running predefined experiments against search engines without the need for a complex evaluation infrastructure. Fig. 2: Screenshot of the interface for precision/recall analysis. Two methods for evaluating a search technique are provided. Quality judges on the relevance of matches in a search result with respect to a human assessment and therefore needs a reference data set. For similarity search, such a dataset has been introduced in [3]. Performance addresses the resource consumption of the implementation of a search engine and its scalability with regard to large process model collections. Hence, performance can be evaluated without a human data set, using any process model collection. For this purpose, a number of time measurements and counters are provided through an API, which can be uses during the execution of a search run by a dedicated search engine. Features, such as support for laps and persistence of counters and timers over multiple search requests are available. All measurements are automatically included in the response of a query, along with statistical measures such as average, median, quantiles, standard deviation, etc. To evaluate a search technique, we developed a web-based evaluation interface that allows choosing among a set of quality and performance evaluation methods, e.g., computation of precision and recall values and the visualization of precision- recall curves. With regards to performance measures, trend analyses can be 4 Christian Ress and Matthias Kunze plotted over a number of search runs for various sizes of the candidate model collection. Fig. 2 shows an excerpt of the evaluation interface that allows choosing a dedicated search engine and compute precision and recall values for each of the queries. The result is provided in a table for each query, and a visualization shows the queries in a coordinate system. This allows for fast identification of queries with significantly good (right upper quadrant) or poor (left lower quadrant) quality. 4 Architecture The search platform has been implemented as Search Evaluation a two-tiered web application, consisting of an Web Interface HTML5 frontend and a Java backend, depicted in R R Fig. 3. The web-search and evaluation interfaces Platform Server are implemented as web applications that run in R common web browsers and require no installation. R They communicate with the search platform via a Index Index Model R Cache JSON API and prove for the interaction with the R user. For search, a simplistic process model editor Query Repository Processor based on the processWave editor2 is provided to formulate the query. Search results are provided Search Engine Process Models as an ordered list along with quality measures, cf. [4]. Evaluation offers predefined experiments, Fig. 3: Architecture of Process i.e., a set of queries and candidates, run against Model Search Platform a dedicated search engine and visualizes results in terms of quality and performance. Particular techniques to match a query with models from the process model repository are realized in dedicated search engines. Search and Evaluation interfaces communicate with the platform server. As an evaluation comprises running reference searches, the platform server does not distinguish between search and experiment. That is, the experiment framework is implemented completely client-side. The search platform server integrates different dedicated search engines. Such an engine comprises at least a query processor that decides, whether a candidate matches the query and scores relevance. A custom index enables efficient search. To facilitate the implementation of these components, the search platform provides shared components that can be accessed by the components of a search engine, i.e., a model cache that underpins a custom index and a persistence interface with the repository that manages stored process models. The model cache increases startup speed as it preserves data that has been expensively precomputed, when models are loaded. Through our strict use of a generic JSON API to access the search platform server it could also be used as a web service for process search and be integrated with other services or applications. 2 http://processwave.org An Extensible Platform for Process Model Search and Evaluation 5 5 Maturity & Show Case The search platform has been implemented as a prototype to elaborate on the requirements on search engines and their integration with a common platform. Since dedicated search methods require their own query processor and indexes, such a platform provides users with a unique search interface that covers various perspectives of process model search, including similarity search and querying. At the current state, we have implemented similarity search and querying based on successor relations, cf. [5,6]. As matching is conducted on net-based formalisms, search results are currently presented using their Petri net representations. This shall be extended in future work. Also, the quality experiments are limited to human assessment of similarity, cf. [3], as other reference data was not available. In the demo, we address researchers that are interested in process model search and may even have proposed a search technique on their own. We will introduce the platform and its architecture in a brief presentation before turning to a live demo that comprises two parts. 1. We demonstrate the search and evaluation capabilities of the platform by means of example queries, and their results. This includes a discussion of search result quality metrics and how they support users in understanding a search result. For evaluation, we show how various measures and diagrams give insight into the quality and performance of a search technique. 2. In a quick walkthrough tutorial, we explain the requirements of a custom search engine and which steps are required to integrate it into the platform by a simple example. A screencast demonstrating our search and evaluation platform can be found at: http://vimeo.com/ress/process-search-demo. The platform is publicly available under the MIT open source license along with a short tutorial on how to use it and integrate a custom search engine at http://bitbucket.org/ress/ process-search. References 1. A. Awad. BPMN-Q: A Language to Query Business Processes. In EMISA, volume 119, pages 115–128, 2007. 2. R. Dijkman, M.L. Rosa, and H.A. Reijers. Managing Large Collections of Business Process Models—Current Techniques and Challenges. Comput Ind, 63(2):91, 2012. 3. R. Dijkman, M. Dumas, B. Dongen, R. Käärik, & J. Mendling. Similarity of Business Process Models: Metrics and Evaluation. Inform Syst, 36(2):498 – 516, 2011. 4. M. Guentert, M. Kunze, and M. Weske. Evaluation Measures for Similarity Search Results in Process Model Repositories. ER ’12, pages 214–227, Springer, 2012. 5. M. Kunze, M. Weidlich, and M. Weske. Behavioral Similarity—A Proper Metric. In BPM ’11, pages 166–181. Springer, 2011. 6. M. Kunze and M. Weske. Local Behavior Similarity. In BPMDS ’1, volume 113 of LNBIP, pages 107–120. Springer, 2012. 7. N. Lohmann, E. Verbeek, and R. Dijkman. Petri Net Transformations for Busi- ness Processes—A Survey. In Transactions on Petri Nets and Other Models of Concurrency II, pages 46–63. Springer, 2009. Worklr: Supporting and Capturing Business Processes from Knowledge Workers David Martinho and António Rito Silva 1 Instituto Superior Técnico – UL 2 ESW - INESC-ID davidmartinho,rito.silva@ist.utl.pt Abstract. Worklr (Workflow enhanced with Live Recommendations) is a workflow tool that relies on one of the most known user experience (UX) pattern: the exchange of email messages. In organizations that do not have workflow systems guiding their business processes, knowledge workers rely on technologies like telephone, email or fax, to interact and attain their business process goals. Knowledge workers operate the busi- ness in a daily basis, and they know how to handle the most complex business situations. Worklr supports the capture of workers’ knowledge following a design-by-doing approach. Workers attain business goals by producing data objects. The convergence of workers’ behavior is fostered through a recommender system. This novel proposal leverages on data- driven workflow approaches. Keywords: Ad-hoc Workflow, Operational Support, Recommender Sys- tems 1 The Worklr Tool Approach Our approach to capture knowledge workers’ tacit knowledge is based on an ad-hoc workflow system which implements conversational acts, and where busi- ness goals are achieved when a set of data objects is produced [1]. Knowledge workers are responsible to produce data objects towards the complete genera- tion of the information required for the process goal achievement. Additionally, knowledge workers can establish conversational acts to request the production of data objects by their co-workers. Associated to a request, the initiator may in- clude some input data objects, and the executor is expected to reply with output data objects that she produced to fulfill the request. The flow of conversational acts (i.e. requests), supported by the ad-hoc workflow system, is driven by the knowledge workers’ knowledge of their own organizational responsibilities and their co-workers responsibilities: they know who is responsible to produce what. Consider a Travel Process case where an employee wants to go on a business travel to Beijing. First, he creates a process instance named Travel Process. As he initiates such process instance, the employee is automatically assigned to execute the first request of the process, a.k.a. root request. It is within this root request, automatically named after the process name, that the employee will create any necessary sub-requests. The employee knows that the secretary is responsible to handle his trip, but before he sends her a sub-request, he creates a set of data objects that he knows the secretary will need. Therefore, the employee creates a data object labeled Destination and fills its value with Beijing, two data objects labeled Departure Date and Returning Date with the values 25/08/2013 and 30/08/2013, respec- tively, and a data object labeled Motivation where he states that he wants to attend the BPM2013 conference. For now, these four data objects are defined as the creation context of the request identified by the request label Travel Process3 . Having the necessary data objects, the employee is in condition to send a sub-request to the secretary. To do so, he creates a new sub-request, chooses the secretary’s queue as destination, names the request Travel Request, adds a little description to communicate the motivation for that request as a commen- tary, and selects all the data objects he created before: Destination, Departure Date, Returning Date and Motivation. As the employee sends the sub-request, that request is published in the secretary’s work queue. As one secretary claims the request for execution, she is proclaiming herself as the executor of that request, being able to see the data objects provided by the request’s initiator. Having the information provided by the employee, the secre- tary calls some travel agencies to request some hotel and flight prices. However, before booking any hotel room or flight, the secretary needs an authorization from the supervisor. Similarly to the employee, the secretary also knows that the supervisor needs to know the trip details and the best tender value she got from the agencies. As such, she creates a data object named Tender and fills it up with the best price she got from the travel agencies. Afterwards, the secretary creates a new sub-request, which she addresses to the supervisor’s queue, labels the request Travel Authorization, writes a comment on what she needs from the supervisor, and, as input, she selects the data objects labeled Motivation, Departure Date, Returning Date, Destination and Tender. In the same way, as the request is sent, it is published in the supervisor’s queue. As one of the supervisors claims this request for execution, he can see the data objects that the secretary attached as input of the request. Based in this data, the supervisor executing the request decides to either authorize or not the travel. To let the secretary know that she can proceed with the hotel and flight booking, the supervisor creates a new data object labeled Authorization and defines its value as Granted. Then, the supervisor is in condition of responding to the request and let the secretary know of his decision. Notice that the secre- tary will only see the data object if the supervisor explicitly selects it when he responds to the request. After the supervisor responds to the request, he cannot create any sub-request or data objects in that context4 . 3 The root request is created automatically and named after the process name 4 Although this requirement appears to be limitative, its for correctness purposes After the supervisor replies to the Travel Authorization request, the secre- tary can see the responded data object Authorization along with its Granted value. Based on that positive value, the secretary calls the travel agency and books the hotel and flight, obtaining the respective reservation number and flight ticket number. With this information, she creates two data objects labeled Hotel Reservation and Flight Number and fills in the respective information. After this, she is in condition to respond to the original request initiated by the employee, providing both the Hotel Reservation and Flight Number data objects. As the secretary responds to the request, the employee can see the hotel and flight information contained in the data objects included in the response. Since he needs no more information, and has no pending or executing sub-requests, the employee completes the process. With the process completed, the employee is essentially saying that the pro- cess attained its goal, which consists in getting the travel approved and both the hotel and flight information. During the process execution, several data ob- jects were produced and drove the process instance. Worklr considers all the created data objects and stores their set of labels, along with their cardinality, as a business process goal. This means that completing the process depicted in the example above results in a process goal with the following eight data object labels: – 1 x Destination – 1 x Motivation – 1 x Departure Date – 1 x Returning Date – 1 x Tender – 1 x Authorization – 1 x Hotel Reservation – 1 x Flight Number Having this process goal is important to guide future business process in- stances under the same label, i.e. process instances labeled Travel Process. Worklr knows, that if in the past a particular process goal was attained, it is likely that same goal will be attained again in a future execution of that kind of process. Hence, along with other contextual information gathered during the execution of a business process instance, Worklr uses such business process goal information and inspects the current state of the process to recommend the cre- ation of new data objects or sub-requests. Such recommendations are based on a process goal and the current execution context, i.e. the user’s roles, the labels of data objects available to the user, and the overall process’ data object labels. Therefore, apart from providing operational support, Worlr is also capable of storing previous executions in a structured way, which contain information to guide future process instances with the same label. Nevertheless, as new business situations occur (e.g. if the supervisor refuses the authorization), the Worklr ah-hoc aspect supports that change, i.e. it does not enforce recommendations, and stores the new attained process goal. That new process goal is taken into consideration in the following executions of processes labeled Travel Process. 1.1 Features The tool is in its first prototype stage, and its source code is not available yet due to intellectual property restrictions inherent to the PhD status of one of the authors. The following list highlights a set of core functionalities of the Worklr appli- cation, regarding operational support: – Create new business process instances. – Create data objects within the execution of a request. – Edit data objects created within the execution of a request. – Create sub-requests and publish them into user and role queues. – Claim requests received in the Inbox for execution. – Communicate with the initiator of the executing request. – Communicate with the executor of the sub-request. – Cancel pending and executing sub-requests. – List all sub-requests initiated and see their respective status (pending, exe- cuting, completed, canceled). – Provide data objects as input of sub-requests. – Respond to executing requests, specifying which data objects should be in- cluded in the response. – Complete business process instances. Apart from operational support, Worklr saves executions in the form of re- quest templates, which are entities that abstract the different completed requests by storing some contextual information. A request template is therefore com- posed by: – an initiator role context, which is essentially the set of organizational roles played by the initiators of that kind of request. – an input data context, which is the set of data object labels, and respective cardinality, of the data objects provided as input in that kind of request. – a creation data context, which is also a set of data object labels, and respec- tive cardinality, created in that kind of request. – an output data context, which, analogously, is the set of data object labels, and respective cardinality, responded in that kind of request. Along with all the business process goals attained under a particular process label, e.g. Travel Process, the Worklr tool provides a recommender system that analyses the context of execution of the current user, and computes a set of rec- ommendations of both the labels of the data objects that should be created, and the labels of the sub-requests that can also be created. To each recommendation is associated a score, as discussed in [2], from which the list of recommendations is ordered accordingly. Hence, the list of Worklr features is extended by this recommender system, and the tool can also: – Provide sub-request recommendations based on the current execution con- text. – Provide data creation recommendations based on the current execution con- text. As users perceive recommendations as useful, they are re-using the labels and behavior from other organizational parties playing a similar set of roles. Additionally, although the number of process, request and data object instances increase as more cases are handled, if recommendations are followed, the number of request templates and data object templates converges and recommendations become more accurate. 1.2 Experiment As shown in the screencast of the tool5 , Worklr is in a functional state enough to conduct an experiment. In [3], we discuss the results of an experiment that we recently conducted, where we gathered some important feedback. In the experiment, we had 13 participants and 1 confederate. The confed- erate would initiate new process instances and the root request, while the 13 participants were distributed across 4 distinct organizational roles that should cooperate to attain a particular business process goal. The business process used in the experiment was similar to the one exemplified here, but with more business rules. A last comment on the experiment: we gathered some important results from the tool as we perceive some convergence in the use of labels by different par- ticipants. In the cold-start of the experiment, users would use different labels to identify requests and data objects, but after 16 business process instances, we identified some interesting convergence results. Acknowledgement This work was supported by national funds through FCT – Fundação para a Ciência e a Tecnologia, under project PEst-OE/EEI/LA0021/2013. References 1. Martinho, D., Silva, A.: Non-intrusive capture of business processes using social software. In: BPM Workshops, pp. 207–218. Springer (2012) 2. Martinho, D., Silva, A.: A recommendation algorithm to capture end-users’ tacit knowledge. Business Process Management 7481, 216–222 (2012) 3. Martinho, D., Silva, A.R.: An experiment on capturing business process from knowl- edge workers, submitted to the BPMS2 Workshop at BPM2013 5 http://vimeo.com/user4862900/worklr-demo-bpm2013 - Password: BPM2013 Declarative Process Mining with the Declare Component of ProM Fabrizio Maria Maggi? University of Tartu, Estonia f.m.maggi@ut.ee Abstract. Traditional process mining techniques mainly work with pro- cedural modeling languages (like Petri nets) where all possible orderings of events must be specified explicitly. However, using procedural pro- cess models for describing processes working in turbulent environments and characterized by a lot of variability (like healthcare processes) is extremely difficult. Indeed, these processes involve several possible exe- cution paths and representing all of them explicitly makes the process models quickly unreadable. Using declarative process models (like De- clare) ensures flexibility in the process description. Even processes that work in environments where participants have more autonomy and are, therefore, more unpredictable can be represented as compact sets of rules. In the process mining tool ProM, there are several plug-ins that can be used for different types of analysis based on Declare ranging from the discovery of Declare models, to conformance checking, to the online monitoring of running process instances. 1 Introduction Process discovery, conformance checking and process model enhancement are the three basic forms of process mining [9]. In particular, process discovery aims at producing a process model based on example executions in an event log and without using any a-priori information. Conformance checking pertains to the analysis of the process behavior as recorded in an event log with respect to an existing reference model. Process model enhancement aims at enriching and extending existing process models with information retrieved from logs, e.g., a process model can be extended with performance-related information such as flow time and waiting time. In the last years, several works have been focused on process mining tech- niques based on declarative process models [2–4, 6–8]. These techniques are very suitable for processes characterized by high complexity and variability due to the turbulence and the changeability of their execution environments. The di- chotomy procedural versus declarative can be seen as a guideline when choosing ? The author would like to thank R.P. Jagadeesh Chandra Bose, Andrea Burattin, Massimiliano de Leoni and Luciano Garcı́a-Bañuelos for their collaboration in the implementation of the plug-ins presented in this paper. Fig. 1. Screenshot from the Declare Maps Miner. the most suitable language to represent models in process mining algorithms: process mining techniques based on procedural languages can be used for pre- dictable processes working in stable environments, whereas techniques based on declarative languages can be used for unpredictable, variable processes working in turbulent environments. The plug-ins presented in this paper use the Declare notation [10]. Declare is a declarative language that combines a formal semantics grounded in Linear Temporal Logic (LTL) on finite traces. A Declare model consists of a set of con- straints which, in turn, are based on templates. Templates are abstract entities that define parameterized classes of properties and constraints are their concrete instantiations. In this paper, we illustrate how the presented plug-ins work by showing their application in the context of the BPI Challenge 2011 [1] that records the treat- ment of patients diagnosed with cancer from a large Dutch hospital. This demon- strates that they are viable to handle event logs of real-life size. 2 Plug-ins Description Through the Declare Maps Miner, it is possible to generate from scratch a set of Declare constraints representing the actual behavior of a process as recorded in an event log. The user selects from a list of Declare templates the ones to be used for the discovery task, i.e., the mined model will contain only constraints that are instantiations of the selected templates. In addition, the user can provide the plug-in with some a-priori knowledge (if it is available), to guide the discovery task. For example, the user can decide to limit the possible constraints to dis- cover. This allows her to generate only constraints that are the most interesting from the domain point of view, thus reducing the complexity of the resulting models. There are two mechanisms for limiting the possible constraints to discover. First, it is possible to ignore constraints between event types (such as start and complete) of the same activity.1 Secondly, the user can provide different groups of activities (each group can be loaded in the form of a list of activities in a text file) and specify if only intra-group or inter-group constraints should be consid- ered. Intra-group constraints refer to the class of constraints where the activities involved all emanate from a single group. In many scenarios, analysts would be interested in finding constraints between activities pertaining to a functionality, to a particular department in an organization, etc. For example, in a hospital event log, an analyst would be interested in finding relationships/constraints be- tween the various administration activities. Inter-group constraints refer to the class of constraints where the activities involved belong to two different groups. For example, in a hospital log, an analyst would be interested in constraints between activities involved in surgery and therapy. The user can also specify thresholds for parameters minimum support and alpha. Parameter minimum support allows her to select the percentage of traces in which a constraint must be satisfied to be discovered (and to filter out noisy traces). Parameter alpha can be used ignore constraints that are trivially true in the discovery task. For example, constraint response(A,B), specifying that if A occurs, then eventually B follows, is trivially true in process instances in which A does not occur at all. Fig. 12 shows the output produced by the Declare Maps Miner. The discovery results are presented to the user as interactive maps and give different informa- tion about the process. Activities (shown as rectangles) are colored based on their frequency (from white indicating low frequency to yellow indicating high frequency). The user can highlight, in the discovered maps, the Declare con- straints (shown as arcs between activities) that are more relevant (based on different metrics) or prune out the ones that are less interesting, redundant or deriving from noise in the log. The maps produced by the Declare Maps Miner also show delays, latencies, time distances between activities and several statis- tics related to the temporal dimension of the process. If an existing Declare model is already available, it is possible to repair it based on the information retrieved from a log (plug-in: Repair a Declare Model ). The user can decide which aspects must be kept in the original set of rules and which ones can be discarded. For example, the user can decide to keep only certain types of constraints or constraints involving certain activities. It is possible to just remove less interesting or redundant rules or to strengthen (if possible) the constraints included in the original set. Starting from a Declare model and from a log, the Declare model can be extended with time information (plug-in: Extend a Declare Model with Time Information). Through the Data- Aware Declare Miner, it is also possible to discover constraints enriched with data conditions. 1 The miner is able to deal with non-atomic activities and to discover constraints involving different parts of the activities’ lifecycle. 2 For space reasons, the quality of the screenshots here presented is not the best. However, all the figures included in this paper are available at http://math.ut.ee/ ~fabrizio/BPMdemo13/demo/FiguresDemo2013.zip Fig. 2. Screenshot from the Declare Diagnoser. Fig. 3. Screenshot from the Declare Analyzer. The Declare Replayer and the Declare Diagnoser (Declare Checker pack- age) can be used to check the conformance of the actual behavior of a process as recorded in an event log with respect to a reference Declare model. The Declare Replayer generates a set of alignments between the log and the De- clare model, i.e., information about what must be changed in the log traces to make them perfectly compliant with the model. The Declare Diagnoser projects the results obtained through the Declare Replayer onto the reference model (as shown in Fig. 2). This projection produces a map in which the critical activi- ties/constraints of the reference model are highlighted. In particular, activities are colored from red to green according to the number of moves they are in- volved in, i.e., according to how many times they were in the wrong place in the log or missing when required. Constraints are colored from red to green based on the number of moves that are needed to make the log compliant to them. Through the Declare Analyzer (Fig. 3), the user can pinpoint where the process execution deviates from the reference Declare model and quantify the degree of conformance of the process behavior through several metrics, e.g., fulfillment ratio and violation ratio. For completeness, we mention that, with Mobucon LTL (a provider of the operational support service in ProM), it is also possible to monitor a running process with respect to a reference Declare model and get information about its compliance at runtime. However, this functionality has already been presented in [11]. 3 Summary The plug-ins belonging to the Declare component of ProM are advanced pro- totypes and, as demonstrated through their application to the log provided for the BPI challenge 2011, are able to handle logs of real-life size. The De- clare Maps Miner and Mobucon LTL have been used in the Poseidon project (http://www.esi.nl/short/poseidon/) to monitor sea vessels. In particular, in [5], we show how it is possible to construct Declare models from real-life historical data and monitor live data with respect to the mined model. We consider the set of ProM plug-ins presented here stable enough for eval- uating the declarative approach in real-life case studies. Binaries and source code can be obtained from the ProM repository (https://svn.win.tue.nl/ repos/prom) and a release of each plug-in including the functionalities de- scribed in this paper is included in the nightly build version of ProM (www. processmining.org). A screencast of this demo can be found at http://math. ut.ee/~fabrizio/BPMdemo13/demo/demo.html. A flyer with a summary of the functionalities described in this paper is available at http://math.ut.ee/ ~fabrizio/BPMdemo13/demo/DeclareFlyer.pdf. References 1. 3TU Data Center. BPI Challenge 2011 Event Log, 2011. doi:10.4121/uuid:d9769f3d-0ab0-4fb8-803b-0d1120ffcf54. 2. A. Burattin, F.M. Maggi, W.M.P. van der Aalst, and A. Sperduti. Techniques for a Posteriori Analysis of Declarative Processes. In EDOC 2012. 3. Massimiliano Leoni, Fabrizio Maria Maggi, and WilM.P. Aalst. Aligning event logs and declarative process models for conformance checking. In BPM 2012. 4. F. M. Maggi, M. Westergaard, M. Montali, and W. M. P. van der Aalst. Runtime verification of LTL-based declarative process models. In RV 2011. 5. Fabrizio M. Maggi, Arjan J. Mooij, and Wil M. P. van der Aalst. Analyzing Vessel Behavior using Process Mining, chapter Poseidon book. 6. F.M. Maggi, J.C. Bose, and W.M.P. van der Aalst. Efficient discovery of under- standable declarative models from event logs. In CAiSE 2012. 7. F.M. Maggi, R.P.J.C. Bose, and W.M.P. van der Aalst. A knowledge-based inte- grated approach for discovering and repairing declare maps. In CAiSE 2013. 8. F.M. Maggi, M. Montali, M. Westergaard, and W.M.P. van der Aalst. Monitoring business constraints with linear temporal logic: An approach based on colored automata. In BPM 2011. 9. W.M.P. van der Aalst. Process Mining: Discovery, Conformance and Enhancement of Business Processes. Springer, 2011. 10. W.M.P. van der Aalst, M. Pesic, and H. Schonenberg. Declarative Workflows: Balancing Between Flexibility and Support. Computer Science - R&D. 11. Michael Westergaard and Fabrizio Maria Maggi. Declare: A tool suite for declar- ative workflow modeling and enactment. In BPM (Demos), 2011. Leveraging Super-Scalarity and Parallelism to Provide Fast Declare Mining without Restrictions Michael Westergaard1,2? and Christian Stahl1 1 Department of Mathematics and Computer Science, Eindhoven University of Technology, The Netherlands 2 National Research University Higher School of Economics, Moscow, 101000, Russia m.westergaard@tue.nl, c.stahl@tue.nl Abstract. UnconstrainedMiner is a tool for fast and accurate mining Declare constraints from models without imposing any assumptions about the model. De- clare models impose constraints instead of explicitly stating event orders. Con- straints can impose various choices and ordering of events; constraints typically have understandable names, but for details, refer to [5]. Current state-of-the-art mining tends to fail due to a computational explosion, and employ filtering to reduce this. Our tool is not intended to provide user-readable models, but in- stead to provide all constraints satisfied by a model. This allows post-processing to weed out uninteresting constraints, potentially obtaining better resulting mod- els than making filtering beforehand out of necessity. Any post-processing (and complexity-reducing filtering) possible with existing miners is also possible with the UnconstrainedMiner; our miner just allows more intelligent post-processing due to having more information available, such as interactive filtering of models. In our demonstration, we show how the new miner can handle large event logs in short time, and how the resulting output can be imported into Excel for further processing. Our intended audience is researchers interested in Declare mining and users interested in abstract characterization of relationships between events. We explicitly do not target end-users who wish to see a Declare model for a particular log (but we are happy to demonstrate the miner on other concrete data). Processes that are not perfectly understood or have little structure, are often easier mod- eled using a declarative rather than a classical imperative approach. In a declarative ap- proach, constraints between tasks are described rather than for each task specifying the next task to execute. Declarative modeling is a more recent and less matured approach, which has so far not found widespread application in industry yet. Declare [7] is an emerging language studied in academia over the last decade. Existing miners. Typically the complexity of checking a constraint is O m · nk · k! ,   where m is the number of traces in the log, n is the number of different events in the entire log, and k is the number of parameters to the  constraint (number of ways to as- sign n events to k ordered parameters – n Pk = nk · k! – times the number of traces k). ? Support from the Basic Research Program of the National Research University Higher School of Economics is gratefully acknowledged. For the BPI challenge log from 20123 [1] the parameters are m = 13, 087 and n = 24, yielding from 314, 088 (k = 1) to 66, 749, 981, 760 (k = 5) checks. ProM 6 has a Declare miner which systematically checks each constraint and returns a model com- prising constraints satisfied for a certain percentage of traces. Due to the complexity, this miner employs a couple of tricks, including forcing users to pick among interest- ing constraints [3], employing a priori reduction to avoid considering rarely occurring events [3], and considering the relationships between constraints to avoid mining some constraints [4]. Even so, the ProM Declare miner did not mine a single constraint such as succession in 24 hours. The assumption that rarely occurring Low risk events need not be checked is crucially dependent on the notion of support, i.e., • X X that a constraint is only interesting if it High risk is triggered. This is problematic in a case such as Fig. 1. There we have a hypothet- Fig. 1: Model with a branch. ical XOR-split and -join. If the top path is chosen, constraints in the bottom part are never triggered, so their support is low, even though those are arguably more interesting. If we want to mine without enforcing high support, we cannot use a priori reduction. Exploitation of relationships between constraints is problematic if we want to display a simpler model, e.g., by removing constraints redundant due to transitivity. The problem here is that, generally, support of a removed constraint cannot be derived from support of the remaining constraints. The MINERful miner [2] uses regular expressions and global computations to mine constraints. First statistics are computed for the log and subsequently constraints are mined from these. The MINERful miner can mine all constraints for the 2012 BPI challenge log in approximately 26 seconds, but only supports a subset of all constraints. Computation of constraints from statistics makes it difficult to add new constraints, as it is necessary to develop and prove rules for doing so. For example, it is far from obvious how to extend this approach to also mine choices. Removing all assumptions. Instead, we prefer to mine first and, subsequently, filter with full information. Not only does this avoid the problem of support and branches, it allows us full knowledge of all constraints, so we can remove redundant constraints more intelligently using simple patterns. Finally, this allows us to provide users with a slider and let them interactively (and locally) balance between simplicity and support. Efficient preprocessing. We first make sure that our base mining algorithm is efficient. We transform the log into a simple array of arrays of identifiers instead of actual events. Declare constraints have a (finite) LTL semantics, which can be represented as a finite automaton. Using a precomputed mapping between event identifiers and automaton labels, we obtain a fast and memory-efficient replay of the log. We can mine most of Declare’s 34 constraints (excluding 2 with four or more parameters) on the BPI challenge log in 249 seconds using 12 MB of memory (including storing the log and all 3 We use the 2012 log as the 2013 log is much simpler with 819 ≤ m ≤ 7554 and 3 ≤ n ≤ 4. results). We mine the same set of constraints as MINERful in 32 seconds (vs 26). This is done automatically, making it easy to add constraints by entering their LTL semantics. Symmetry reduction. We observe that some Declare constraints are symmetric in their parameters; this is, for example, the case for the choice 1 of 2 constraint. By only checking these constraints for one ordering of parameters, we halve the num- ber of checks (and time needed). In general, this reduces the checking complexity to O m · nk · k! ÷ sg∈SG |sg|! , i.e., divided by the faculty of the size of each sym-  Q metry group sg ∈ SG. The number we divide by tends to get larger exactly when the traditional approach has problems (i.e., when k is large). For example, the most com- plex standard Declare constraint is choice 1 of 5, which yields the aforementioned 67 billion checks for the BPI challenge log. As this constraint is symmetric in all pa- rameters, this is reduced to 556, 249, 848 checks. Our implementation can mine all 34 Declare constraints for the BPI challenge log in 287 seconds (so the reduction allows us to check all constraints in the same amount of time we could only check the easy ones before). We now tie with MINERful at 26 seconds (the reason for less reduction is that MINERful does not handle any constraints where the reduction is large). For the standard constraints, we never have more than two symmetry groups, which means that as number of parameters go up, so does the reduction. We compute the symmetry reduction automatically, making this compatible with any added constraint. Parallelization. As our miner is simple, we do not need any global computations so far. This means our miner is easy to parallelize. We can parallelize in the number of constraints or the number of traces. With 34 constraints, we can mine each individually. Declare constraints are not equal however, and indeed the choice 1 of 5 constraint is responsible for more than 50% of the total time spent on the BPI challenge log, making this strategy less compelling. As we generate the parameters for the mining determin- istically, we can have each computation thread take care of this on its own, alleviating this (but making mining more complex). A simpler approach, and the one we have cho- sen to go with, is to split the log and have each computation thread handle part of the log. As we have abolished a priori reduction, we do not need any central coordination in this case, and our overhead is so small (< 1 second) we can just run the full min- ing process for each part of the log. Our results can be directly added, making mining scalable nearly infinitely (with constant overhead for preprocessing and aggregation). This has the added benefit of allowing each thread to use less memory (it only needs to store its own part of the log). Employing this allows us to mine all constraints of the BPI challenge log in 174 seconds (using two cores; the reason scalability is not com- pletely linear is due to the feature Turbo Boost on modern CPUs allowing one core on a multi-core system to run at extra speed if other cores are inactive). We beat MINER- ful at 19 seconds (vs 26). We have implemented this in a parallel setting (i.e., multiple CPU cores on a single machine), but it is equally applicable in a distributed setting as synchronization is only necessary for aggregating results at the end. Super-scalar mining. Using the automaton representation from [6], it is possible to check more than one constraint at a time. This comes at a cost of memory as the com- bined automaton is larger than the individual automata, sometimes even exponentially so, though in practise the size is always less than 1,000 states. We call this super-scalar mining, using the term from CPUs where it refers to the ability to execute multiple instructions simultaneously. We do not wish to break our symmetry reduction from be- fore. Thus, we build a directed acyclic graph with constraints for nodes and arcs from one constraint to another if the first implies the second holds. We then group by taking each leaf and iteratively grouping it with all predecessors and successors not extend- ing the set of parameters and not having incompatible symmetry groups (e.g., splitting them up so [[A], [B]] is not compatible with [[A, B]]—it would split up the symmetry group—but the other way around does hold—the symmetry group is already split). The rationale is that adding new parameters increases complexity as does splitting symmetry groups. Adding a constraint with larger symmetry groups does not increase complexity, while the constraint with larger symmetry groups could be checked more efficient on its own, adding to the super-scalar group comes at no extra cost. We check all such maxi- mal groups. We compute this automatically and tailor it to any constraints selected and any new constraints added. Using super-scalar mining with parallelism, we can mine the entire BPI log in only 57 seconds and even without parallelism, we can mine the entire log in just 92 seconds. We beat MINERful on their constraints at just over 4 seconds, an improvement of a factor 6 over 26 seconds. On a server with 8 slower processing cores, MINERful still runs in 26 seconds, whereas UnconstrainedMiner runs in 30 seconds on the entire set of constraints. Using hyper-threading, the UnconstrainedMiner and MIN- ERful tie in running time with the UnconstrainedMiner mining more and more complex constraints. The gain obtained by super-scalar mining is independent of the log. Fig. 2: Screen shots of our miner running. Usage. In Fig. 2 (top) we see a screen-shot from the configuration of the mining process. All options are saved between runs, making mining from scratch a breeze; the number of threads is computed automatically as the number of cores in the local computer. We can manually inspect the LTL semantics and constraint automaton at the right. In Fig.2 (bottom left) we see the tool in the process of mining. The top progress shows overall progress, and the next progress bars show overall and individual con- straint progress for each computation thread. The text area is continuously updated with information about what each thread is doing. At Fig. 2 (bottom right), we see the end result along with total processing time. The end result is a list of all mined constraints, which can be imported in Excel for further processing, as shown in Fig. 3. Maturity, availability, screencast. Our miner is very new but so far very robust, and uses the same underlying library as the Declare tool (for representing automata) and ProM (for reading logs). The tool is written in Java and runs on all platforms supported by Java. We are currently employing the tool to construct hybrid models containing both declarative constraints and imperative modeling in a block-structured manner. Our miner is available from tinyurl.com/declareminer along with source code. That page also contains a screen cast of simple use of the tool. References 1. DOI: 10.4121/uuid:3926db30-f712-4394-aebc-75976070e91f 2. Di Ciccio, C., Mecella, M.: A two-step fast algorithm for the automated discovery of declara- tive workflows. In: CIDM 2013. IEEE (2013) 3. Maggi, F.M., Bose, R.P.J.C., van der Aalst, W.M.P.: Efficient discovery of understandable declarative process models from event logs. In: CAiSE 2012. LNCS, vol. 7328, pp. 270–285. Springer (2012) 4. Maggi, F.M., Bose, R.P.J.C., van der Aalst, W.M.P.: A knowledge-based integrated approach for discovering and repairing declare maps. In: CAiSE 2013. LNCS, Springer (2013) 5. Pesic, M.: Constraint-Based Workflow Management Systems: Shifting Controls to Users. Ph.D. thesis, Beta Research School for Operations Management and Logistics, Eindhoven (2008) 6. Westergaard, M.: Better Algorithms for Analyzing and Enacting Declarative Workflow Lan- guages Using LTL. In: Proc. of BPM. LNCS, vol. 6896, pp. 83–98. Springer (2011) 7. Westergaard, M., Maggi, F.M.: Declare: A Tool Suite for Declarative Workflow Modeling and Enactment. In: Business Process Management Demonstration Track (BPMDemos 2011). CEUR Workshop Proceedings, vol. 820. CEUR-WS.org (2011) Fig. 3: The mining results imported into Excel. wOIS-paan – Discovering Performer-Activity Affiliation Networking Knowledge from XPDL-based Workflow Models Hyun Ahn1 , Minjae Park2, and Kwanghoon Pio Kim1 1 Collaboration Technology Research Laboratory Department of Computer Science KYONGGI UNIVERSITY e-Mail: {hahn, kwang}@kgu.ac.kr http://ctrl.kyonggi.ac.kr 2 BISTel, Inc. e-Mail: mjpark@bistel-inc.com http://www.bistel.co.kr Abstract. In this demo-paper, we implement a workflow-supported or- ganizational intelligence system, which is named as wOIS-paan. The ma- jor functionality of the current version of the system is to explore “work- flow performer-activity affiliation networking knowledge” from an XPDL- based workflow model, and to visualize the knowledge in a graphical form of the force-directed-layout of the Prefuse toolkit. The implemented sys- tem operates under a series of algorithms discovering, analyzing, mea- suring, and visualizing workflow performer-activity affiliation networking knowledge from an XPDL-based workflow package3 , which represents in- volvement and participation relationships, after all, between a group of performers and a group of activities. The eventual goal of the system is to measure and visualize the human resource allotments and contributions in enacting a workflow procedure (or a group of workflow procedures) at a glance. Also, in terms of the scalability of the system, it can be exten- sible to show the organization-wide workflow procedures. Conclusively, the wOIS-paan system ought to be a very valuable tool for the BPM and workflow design and operational performance analyzers and consultants. Keywords: workflow-supported social networking knowledge, workflow affiliation networking knowledge, organizational knowledge discovery, workflow intelligence 1 Maturity In general, a workflow management system consists of two components, the mod- eling component and the enacting component. The modeling component allows 3 A group of workflow models is defined as a workflow package in the WfMC’s stan- dardization terminology. 2 a modeler to define, analyze and maintain workflow models by using all of the workflow entities that are necessary to describe work procedures, and the en- acting component supports users to play essential roles of invoking, executing and monitoring instances of the workflow model defined by the modeling compo- nent. Especially, from the organizational intelligence point of view, the modeling component deals with the planned (or workflow build-time aspect) knowledge of organizational resources allocations for workflow-supported operations, while on the other the enacting component concerns about the executed (or work- flow run-time aspect) knowledge of organizational resources allotments for the workflow-supported operations. With being connected to these view-points, there might be two issues, such as discovery issue[3] and rediscovery issues[4], in terms of the organizational knowledge discovery activities. In other words, the work- flow knowledge discovery issue has something to do with exploring the planned knowledge from workflow models defined by the modeling component, and the workflow knowledge rediscovery issue is to explore the executed knowledge from the execution logs of the workflow models. Conclusively, the demo-system, wOIS- paan, is able to discover, analyze, and visualize the planned knowledge of workflow performer-activity affiliations and allotments on a workflow model or a group of workflow models. Availability of the System. The system’s development environments are listed as followings. Particularly, we suppose that the XPDL workflow package’s release version is XPDL 1.0. So, it is necessary to be refurbished to support the recently released version of XPDL 2.0 or more, which reflects the BPMN4 graphical constructs. – Operating System: Windows 7 Ultimate 64bit – Programming Language: Java Development Toolkit v.6.0 – XPDL Version: XPDL 1.0 – Development Tool: Eclipse Indigo Release 2 – Libraries: Awt/Swing, Prefuse, Xpdl However, the system’s execution environments are any types of operating systems, and the executable system is available on the website of the authors’ research group, the collaboration technology research lab, at the department of computer science, Kyonggi University, https://ctrl.kyonggi.ac.kr/wois.html, and anyone can download the executable system and its demo workflow models in XPDL after registering as a member of the wOIS-paan’s user group. Use Cases and Features. The workflow performer-activity affiliation network- ing knowledge can be not only discovered from a workflow model defined by the modeling component, but also rediscovered from its execution event logs stored by the enacting component. In this demo-paper, we focus on the discovering issue 4 BPMN stands for Business Process Modeling Notations, and it is released by OMG’s BMI (Business Modeling & Integration) Domain Task Force. 3 of the workflow performer-activity affiliation networking knowledge from a work- flow model. That is, the system’s use cases are related with the discovering, an- alyzing, and visualizing features of the planned knowledge of performer-activity affiliations and allotments. The major use cases and their crucial features are listed as the followings: – Discovery Use Case : Import XPDL-based workflow models or packages, Dis- cover the wOIS-paan knowledge, and Generate the bipartite matrix from the discovered knowledge – Analysis Use Case : Calculate the degree centrality of each performer and each activity, and Measure the group-degree centrality of the corresponding workflow models (or packages) – Visualization Use Case : Visualize the graph nodes and edges between per- former and activity in a graphical form of the force-directed-layout of the Prefuse toolkit Fig. 1. Architectural Components of the wOIS-paan Knowledge Discovery System The essential functional components being comprised of the system are bi- partite matrix generation functionality[2], knowledge visualization functionality, and knowledge analysis functionality, and these components also can be sys- tematically implemented by using the Java programming language. Fig. 1 illus- trates a system architecture of the implemented wOIS-paan knowledge discovery system, which is made up of four groups of architectural components—wOIS- paan Window-control, knowledge visualization, bipartite matrix generation, and knowledge analysis components. Particularly, the XPDL parser of the analysis components group takes charge of generating a performer-activity bipartite ma- trix from an XPDL-based workflow package5 , and the social graph visualizer of 5 The system is able to handle a group of XPDL-based workflow models as well as individuals of the workflow models. 4 the visualization components group depicts the wOIS-paan knowledge as a bi- partite graph transformed from the bipartite matrix. In terms of the wOIS-paan knowledge analysis aspect, the system is theoretically backed up by the extended versions of the workload-centrality analysis equations[1], such as actor-degree centrality analysis equations and group-degree centrality analysis equations, so as to mathematically analyze a workflow performer-activity affiliation network model discovered from an XPDL-based workflow package. 2 Significance to the BPM field with a Case Study As an operational example, we try to discover wOIS-paan knowledge from the XPDL-based pseudo-workflow packages arranged in Table 1. We suppose that there are two pseudo-workflow packages, each of which has two workflow mod- els and three workflow models, respectively, and all fifty activities have been conducted by all of the sixteen performers. Consequently, the system is able to successfully discover a wOIS-paan knowledge from the pseudo-workflow pack- ages, and visualize the discovered knowledge as shown in the captured-screen of Fig. 2. In the visualized wOIS-paan knowledge as colored bipartite graph, boxes and circles imply performers and activities, respectively, and the bold-colored box and its linked circles represent the performer, Alan, and his affiliated 11 activities, such as α1 , α9 , α10 , α16 , α21 , α26 , α33 , α36 , α39 , α43 , α50 . Table 1. Specifications of the XPDL-based Pseudo-workflow Packages Workflow Package Workflow Model Workflow Activity Workflow Performer HR-Dept-Workflow- Hiring-Workflow-Model α1 ∼ α16 (16 Activities) Jeff, Ed, Christiaan, Package1 Emily, Adam, Cynthia, Performance- α17 ∼ α25 (9 Activities) Joylette, Amanda, Management- Nathaniel, Bryan, Workflow-Model Tamara, Ashley, Ryan, Alan, Chris, Holly HR-Dept-Workflow- Employee-Training- α26 ∼ α36 (11 Activities) Package2 Workflow-Model Department- α37 ∼ α44 (8 Activities) The same performers in Management- the Package1 Workflow-Model Salary-Negotiation- α45 ∼ α50 (6 Activities) Workflow-Model 3 Conclusion In this demo-paper, we suggested a possible way of projecting a special affilia- tion knowledge of the workflow-supported affiliation relations (involvement and participation behaviors) between workflow-based people and workflow-based ac- tivities by converging the social network techniques and the workflow discov- ering techniques. As a consequence of this suggestion, we have newly defined 5 Fig. 2. Visualization of the Discovered wOIS-paan Knowledge by the System an organizational intelligence of workflow performer-activity affiliation network- ing knowledge, and implemented a knowledge discovery system to explore the performer-activity affiliation networking knowledge from an XPDL-based work- flow package. Conclusively, we have successfully verified the implemented system through applying to two pseudo-workflow packages and visualizing the discov- ered wOIS-paan knowledge from them. Acknowledgement. This research was supported by the Basic Science Research Program (Grant No. 2012006971) through the National Research Foundation of Korea. References 1. David Knoke, Song Yang, SOCIAL NETWORK ANALYSIS - 2nd Edition, Series: Quantitative Applications in the Social Sciences, SAGE Publications, 2008 2. Haksung Kim, et al.,“A Workflow Affiliation Network Discovery Algorithm,” ICIC Express Letters, Vol. 6, No. 3, pp. 765-770, 2011 3. Kwanghoon Kim, “A Workflow-based Social Network Discovery and Analysis Sys- tem,” Proceedings of the International Symposium on Data-driven Process Discovery and Analysis, Campione d’Italia, ITALY, June 29 July 1, 2011 4. Wil M. P. van der Aalst, Hajo A. Reijers, Minseok Song, “Discovering Social Net- works from Event Logs,” COMPUTER SUPPORTED COOPERATIVE WORK, Vol. 14, No. 6, pp. 549–593, 2005