《电子商务 E-business》阅读文献：Supporting flexible processes through recommendations based on history

Supporting Flexible Processes Through Recommendations Based on History Helen Schonenberg, Barbara Weber, Boudewijn van Dongen and Wil van der Aalst Eindhoven University of Technology, Eindhoven, The Netherlands im hschonenberg, b f v dongen, w.m. p v.d. aalst@tue. nl] otue nl Department of Computer Science, University of Innsbruck, Austria Barbara. Weberquibkacat Abstract. In today' s fast changing business environment flexible Pro- cess Aware Information Systems(PAISs) are required to allow companies to rapidly adjust their business processes to changes in the environment However, increasing flexibility in large PAISs usually leads to less guid- ance for its users and consequently requires more experienced users. To allow for flexible systems with a high degree of support, intelligent user ssistance is required. In this paper we propose a recommendation ser- vice, which, when used in combination with fexible PAISs, can support end users during process execution by giving recommendations on pos- sible next steps. Recommendations are generated based on similar past process executions by considering the specific optimization goals. In this paper we also evaluate the proposed recommendation service, by means of experiments 1 Introduction In todays fast changing business environment, flexible Process Aware Informa- tion Systems(PAISs)are required to allow companies to rapidly adjust thei business processes to changes in the environment 7. PAISs offer promising ment[13), case handling systems [16] and declarative processes [11, 12(or.e perspectives and there are several paradigms, e. g, adaptive process manag overview see 3, 18, 20) In general, in flexible PAis it occurs frequently that users working on a case, i.e., a process instance, have the option to decide between several activities that are enabled for that case. However, for all flexibility approaches, the user support provided by the PAIS decreases with increasing flexibility(cf. Fig. 1) since more options are available, requiring users to have in-depth knowledge bout the processes they are working on. Traditionally, this problem is solved by educating users(e.g, by making them more aware of the context in which a case is executed), or by restricting the PAIS by introducing more and more constraints on the order of activities and thus sacrificing flexibility. Both options however, are not satisfactory and limit the practical application of flexible PAIss

Supporting Flexible Processes Through Recommendations Based on History Helen Schonenberg, Barbara Weber, Boudewijn van Dongen and Wil van der Aalst Eindhoven University of Technology, Eindhoven, The Netherlands {m.h.schonenberg, b.f.v.dongen, w.m.p.v.d.aalst@tue.nl}@tue.nl Department of Computer Science, University of Innsbruck, Austria Barbara.Weber@uibk.ac.at Abstract. In today’s fast changing business environment flexible Pro￾cess Aware Information Systems (PAISs) are required to allow companies to rapidly adjust their business processes to changes in the environment. However, increasing flexibility in large PAISs usually leads to less guid￾ance for its users and consequently requires more experienced users. To allow for flexible systems with a high degree of support, intelligent user assistance is required. In this paper we propose a recommendation ser￾vice, which, when used in combination with flexible PAISs, can support end users during process execution by giving recommendations on pos￾sible next steps. Recommendations are generated based on similar past process executions by considering the specific optimization goals. In this paper we also evaluate the proposed recommendation service, by means of experiments. 1 Introduction In todays fast changing business environment, flexible Process Aware Informa￾tion Systems (PAISs) are required to allow companies to rapidly adjust their business processes to changes in the environment [7]. PAISs offer promising perspectives and there are several paradigms, e.g., adaptive process manage￾ment [13], case handling systems [16] and declarative processes [11, 12] (for an overview see [3, 18, 20]). In general, in flexible PAIS it occurs frequently that users working on a case, i.e., a process instance, have the option to decide between several activities that are enabled for that case. However, for all flexibility approaches, the user support provided by the PAIS decreases with increasing flexibility (cf. Fig. 1), since more options are available, requiring users to have in-depth knowledge about the processes they are working on. Traditionally, this problem is solved by educating users (e.g., by making them more aware of the context in which a case is executed), or by restricting the PAIS by introducing more and more constraints on the order of activities and thus sacrificing flexibility. Both options, however, are not satisfactory and limit the practical application of flexible PAISs

In this paper, we present an approach for intelligent user assistance which llows PAISs to overcome this problem and to provide a better balance be- tween flexibility and support. We use event logs of PAISs to gain insights into the process being supported without involving a process analyst and we pro- pose a tooling framework to provide continuously improving support for users of flexible PAISs. At the basis of our approach lie so-called recommendations A recommendation provides information to a user about how he should proceed with a partial case (i.e, a case that was started but not completed yet ),to chieve a certain goal(e.g, minimizing cycle time, or maximizing profit). In this paper we discuss several methods for calculating log-based recommendations. In addition, we describe the implementation of our approach as recommendation service and its evaluation. The remainder of this paper is structured as follows In Section 2, we present the requirements and an overview of the recommenda- tion service. Then, in Section 3 we define a log-based recommendation service. In Section 4, we describe the experiment we conducted to evaluate whether recom- mendations indeed help to achieve a particular goal. Finally, we discuss related work in Section 5 and provide conclusions in Section 6 2 Overview Fig. 2 illustrates the envisioned support of users of flexible PAISs through a recommendation service. In general, each business process to be supported is described as process model in the respective PAIS. We consider both imperative and declarative process models. In fact, our approach is most useful when the process model provides the user a lot freedom to manoeuvre, i.e., multiple activ- ities are enabled during execution of a case. At run-time, cases are created and executed considering the constraints imposed by the process model. In addition the PAiS records information about executed activities in event logs. Typically, event logs contain information about start and completion of activities, their ordering, resources which executed them and the case they belong to 1 As illustrated in Fig. 2, the recommendation service is initiated by a request from the user for recommendations on possible next activities to execute. In this request, the user sends the recommendation service information about the par- tially executed case, i.e.,(1)the currently enabled activities, and(2 )the history of executed activities, which we call the partial trace. Information about the partial trace is required because the decision which activities to perform next for a particular case usually depends on the activities already performed for his case. In addition, only enabled activities are considered to ensure that no recommendations are made that violate the constraints imposed by the process model. The recommendation service then provides the PAis a recommendation result, ie. an ordering of recommendations where each recommendation refers to one activity and some quality attributes(e. g, expected outcome) explaining the recommendation. Recommendations are ordered such that the first recom- mendation in the list is most likely to help the user achieving his goal,i.e

In this paper, we present an approach for intelligent user assistance which allows PAISs to overcome this problem and to provide a better balance be￾tween flexibility and support. We use event logs of PAISs to gain insights into the process being supported without involving a process analyst and we pro￾pose a tooling framework to provide continuously improving support for users of flexible PAISs. At the basis of our approach lie so-called recommendations. A recommendation provides information to a user about how he should proceed with a partial case (i.e., a case that was started but not completed yet), to achieve a certain goal (e.g., minimizing cycle time, or maximizing profit). In this paper we discuss several methods for calculating log-based recommendations. In addition, we describe the implementation of our approach as recommendation service and its evaluation. The remainder of this paper is structured as follows. In Section 2, we present the requirements and an overview of the recommenda￾tion service. Then, in Section 3 we define a log-based recommendation service. In Section 4, we describe the experiment we conducted to evaluate whether recom￾mendations indeed help to achieve a particular goal. Finally, we discuss related work in Section 5 and provide conclusions in Section 6. 2 Overview Fig. 2 illustrates the envisioned support of users of flexible PAISs through a recommendation service. In general, each business process to be supported is described as process model in the respective PAIS. We consider both imperative and declarative process models. In fact, our approach is most useful when the process model provides the user a lot freedom to manoeuvre, i.e., multiple activ￾ities are enabled during execution of a case. At run-time, cases are created and executed considering the constraints imposed by the process model. In addition, the PAIS records information about executed activities in event logs. Typically, event logs contain information about start and completion of activities, their ordering, resources which executed them and the case they belong to [1]. As illustrated in Fig. 2, the recommendation service is initiated by a request from the user for recommendations on possible next activities to execute. In this request, the user sends the recommendation service information about the par￾tially executed case, i.e., (1) the currently enabled activities, and (2) the history of executed activities, which we call the partial trace. Information about the partial trace is required because the decision which activities to perform next for a particular case usually depends on the activities already performed for this case. In addition, only enabled activities are considered to ensure that no recommendations are made that violate the constraints imposed by the process model. The recommendation service then provides the PAIS a recommendation result, i.e., an ordering of recommendations where each recommendation refers to one activity and some quality attributes (e.g., expected outcome) explaining the recommendation. Recommendations are ordered such that the first recom￾mendation in the list is most likely to help the user achieving his goal, i.e

eng ne Fig. 1. PAIS trade-offs 5. Fig. 2. An overview of the recommendation service. optimizing a certain target, such as profit, cost, or cycle time. Different users can have different targets, resulting in different recommendations As an example we describe a fictive process of applying for a building permit at a town hall. Initially, the employee has to do several tasks: (A) bill registration fee(B)register the application details, (C) initiate permission procedure, (D) announce the application in local newspaper, and(E) inform applicant. Th employee can decide in which order to execute these tasks. Ideally, the employee finishes these as soon as possible. All tasks have a fixed duration, however, tasks B and C use the same database application and if is directly followed by C, then the combined duration of the tasks is much shorter, since there is no closing- time for B an not set-up time for C, moreover C can use the data provided by B, without data re-entry. The recommendation service can guide employees to execute in the faster order of tasks In this simple example the use of recommendations seems to be an overkill the user only has to select among a limited set of options. In the presence of real life flexible processes, with increasing complexity there are so ptions for users, that user support becomes fundamental. At the same time, giving recommendations based on extracted knowledge from execution logs can provide knowledge that was not available during the design of the process 3 Log- Based Recommendation Service In this section, we present a concrete definition of a log-based recommendation service for providing users with recommendations on next possible activities to execute. Recommendations for an enabled activity provide predictive informa- tion about the user goal, based on observations from the past, i.e., fully com- ed by their target value(e or pr that have been stored in an event log. The log-based recommendation service requires the presence of an event log that contains such information about cases that have been executed for a certain process

ad-hoc workflow groupware production workflow case handling low high flexibility support Fig. 1. PAIS trade-offs [5]. Recommendation Request partial case enabled activities Recommendation Result ordering enabled activities Optimization goal Event log logs uses Fig. 2. An overview of the recommendation service. optimizing a certain target, such as profit, cost, or cycle time. Different users can have different targets, resulting in different recommendations. As an example we describe a fictive process of applying for a building permit at a town hall. Initially, the employee has to do several tasks; (A) bill registration fee (B) register the application details, (C) initiate permission procedure, (D) announce the application in local newspaper, and (E) inform applicant. The employee can decide in which order to execute these tasks. Ideally, the employee finishes these as soon as possible. All tasks have a fixed duration, however, tasks B and C use the same database application and if B is directly followed by C, then the combined duration of the tasks is much shorter, since there is no closing￾time for B an not set-up time for C, moreover C can use the data provided by B, without data re-entry. The recommendation service can guide employees to execute in the faster order of tasks. In this simple example the use of recommendations seems to be an overkill as the user only has to select among a limited set of options. In the presence of real life flexible processes, with increasing complexity there are so many options for users, that user support becomes fundamental. At the same time, giving recommendations based on extracted knowledge from execution logs can provide knowledge that was not available during the design of the process. 3 Log-Based Recommendation Service In this section, we present a concrete definition of a log-based recommendation service for providing users with recommendations on next possible activities to execute. Recommendations for an enabled activity provide predictive informa￾tion about the user goal, based on observations from the past, i.e., fully com￾pleted traces accompanied by their target value (e.g., cost, cycle time, or profit), that have been stored in an event log. The log-based recommendation service requires the presence of an event log that contains such information about cases that have been executed for a certain process

3.1 Preliminaries Let A be a set of activities. A'" denotes a set of finite sequences over A. A trace o E A'is a finite sequence of activities, where o = n is the length of the sequence Sequences are denoted as a=(a1, a2, -. an) and we denote On traces, we define the standard set of operators Definition1( Trace operators).Leta:{1,…,n}→ A and o′:{1,…,m}→ b be traces with a=(a1, a2,..., an)and o'=(b1, b2,..., bm) Prefix 0≤a→n≤m∧V1<k<na1=b Concatenation o=(a1,a2,……,an,b1,b2,……,bm) Membership a∈a→1<i<na;=a Parikh vector par(o(a)=#o<isn ai=a The Parikh vector par(o)(a) denotes the number of occurrences of a in race o, e. g, par((a, b, c, a, b, c, d)(a)=2 For multi-sets(bags), we introduce standard notation to denote the universe of multi-sets over a given set. Let s be a set, then the universe of multi-sets over S is denoted by with X∈B(S), denoted as X:S→ n is a multi set,where for all s E S holds that X(s) denotes the number of occur of s in X(s). We will use [a, b2, el to denote the multi-set of one a, two b's and three cs as a shorthand for the multi-set X E B(A)where A= a, b, ck X(a)=l, X(b)=2, X(c)=3. Furthermore, multi-set operators such as for for union b, intersection A, and submulti-set C, c are defined in a straightforward way and can handle a mixture of sets and multi-sets Definition 2(Event log). Let a be a set of activities. An event log L E B(4*) a multi-set of traces referring to the activities in A Recall that each recommendation contains predictive information regarding the user goal. For now, we assume that this goal can be captured by a function on a trace, i.e., each trace o in an event log has a target value(e. g, cost, cycle time, or profit )attached to it Definition 3(Target Function). Let a be a set of activities and o E A'a sequence of activities. We define T(o)ER+ to represent the target value of the sEquence o ote that T is not a function, as similar sequences might have different values attached to them. However T is total, i.e. it provides a value for all sequences 3.2 Recommendations A recommendation is initiated by a recommendation request, which consists of a partial trace and a set of enabled activities. Formally, we define a recommen- dation request as follows

3.1 Preliminaries Let A be a set of activities. A∗ denotes a set of finite sequences over A. A trace σ ∈ A∗ is a finite sequence of activities, where |σ| = n is the length of the sequence. Sequences are denoted as σ = ha1, a2, . . . , ani and we denote ∀1≤i≤n σ(i) = ai . On traces, we define the standard set of operators. Definition 1 (Trace operators). Let σ : {1, . . . , n} → A and σ 0 : {1, . . . , m} → B be traces with σ = ha1, a2, . . . , ani and σ 0 = hb1, b2, . . . , bmi. Prefix σ ≤ σ 0 ⇐⇒ n ≤ m ∧ ∀1≤i≤n ai = bi Concatenation σaσ 0 = ha1, a2, . . . , an, b1, b2, . . . , bmi Membership a ∈ σ ⇐⇒ ∃1≤i≤n ai = a Parikh vector par(σ)(a) = #0≤i≤n ai = a. The Parikh vector par(σ)(a) denotes the number of occurrences of a in a trace σ, e.g., par(ha, b, c, a, b, c, di)(a) = 2. For multi-sets (bags), we introduce standard notation to denote the universe of multi-sets over a given set. Let S be a set, then the universe of multi-sets over S is denoted by B(S), with X ∈ B(S), denoted as X : S → N is a multi￾set, where for all s ∈ S holds that X(s) denotes the number of occurrences of s in X(s). We will use Ja, b2 , c3 K to denote the multi-set of one a, two b’s and three c’s as a shorthand for the multi-set X ∈ B(A) where A = {a, b, c}, X(a) = 1, X(b) = 2, X(c) = 3. Furthermore, multi-set operators such as for for union ], intersection C, and submulti-set v, ❁ are defined in a straightforward way and can handle a mixture of sets and multi-sets. Definition 2 (Event log). Let A be a set of activities. An event log L ∈ B(A∗ ) is a multi-set of traces referring to the activities in A. Recall that each recommendation contains predictive information regarding the user goal. For now, we assume that this goal can be captured by a function on a trace, i.e., each trace σ in an event log has a target value (e.g., cost, cycle time, or profit) attached to it. Definition 3 (Target Function). Let A be a set of activities and σ ∈ A∗ a sequence of activities. We define τ (σ) ∈ R + to represent the target value of the sequence σ. Note that τ is not a function, as similar sequences might have different values attached to them. However, τ is total, i.e. it provides a value for all sequences. 3.2 Recommendations A recommendation is initiated by a recommendation request, which consists of a partial trace and a set of enabled activities. Formally, we define a recommen￾dation request as follows

Definition 4(Recommendation request). Let A be a set of activities and P* a partial trace. Furthermore, let e c a be a set of enabled activities We call r=(p, E) An activity accompanied by predictive information regarding the user goal is called a recommendation. For each enabled activity, we determine the expected target value when doing this activity(do), and the expected target value for alternatives of the enabled activity, i.e., other enabled activities( dont ) Precise definitions of do and dont are given in Definitions 10 and 11. A recommendation result is an ordering over recommendations. Definition 5(Recommendations). Let a be a set of activities and L E quest with E SA, E=n and e e e an enabled activity -(e, do(e, P, L), dont(e, P, L))E EXRXR is a recommendation. We use to denote the universe of recommendations A recommendation result R=((el, do(e1, P, L), dont(e1, P, L)), (e2, do(e2, P, L),dont(e2, P, L)),.,(en, do(en, P, L), dont(en, P, L)))is a sequence of rec ommendations, such that RESi and v, The nature of the ordering over recommendations is kept abstract, however, provide a possible ordering for a recommendation result in Example 1, Section 3.6. In the next section we describe how recommendations are generated by the recommendation service based on an existing event log L 3.3 Trace abstraction When generating log-based recommendations only those traces from the event log should be considered, which are relevant for determining the predictive infor- mation of an enabled activity. From those traces the ones with a high degree of matching with the partial trace execution should be weighted higher than those with small or no match To determine which log traces are relevant to provide recommendations for a given partial trace and to weight them according to their degree of match ng we need suitable comparison mechanisms for traces. Our recommendation service provides three different trace abstractions based on which traces can be compared, namely, prefix, set and multi-set abstraction. The prefix abstraction basically allows for a direct comparison between the partial trace and a log trace In practice such a direct comparison is not always relevant, e. g, when the order ing, or frequency of activities is not important. Therefore we provide with set and multi-set two additional abstractions. They are independent of the domain context, e. g, they do not assume the process to be a procurement process or an invoice handling process 17 Definition 6(Trace abstraction). Let A be a set of activities, LE B(Abe an event log and oEL be a trace. o, o denotes the prefer abstraction of o, os =al aeo denotes the set abstraction of o and om =par(o) denotes the multi-set abstraction of o, i.e., for all a e o holds that m(a)=par(o(a)

Definition 4 (Recommendation request). Let A be a set of activities and ρ ∈ A∗ a partial trace. Furthermore, let E ⊆ A be a set of enabled activities. We call r = (ρ, E) a recommendation request. An activity accompanied by predictive information regarding the user goal is called a recommendation. For each enabled activity, we determine the expected target value when doing this activity (do), and the expected target value for alternatives of the enabled activity, i.e., other enabled activities (dont). Precise definitions of do and dont are given in Definitions 10 and 11. A recommendation result is an ordering over recommendations. Definition 5 (Recommendations). Let A be a set of activities and L ∈ B(A∗ ) an event log over A. Furthermore, let (ρ, E) be a recommendation re￾quest with E ⊆ A, |E| = n and e ∈ E an enabled activity. – ￾ e, do(e, ρ, L), dont(e, ρ, L)
∈ E × R × R is a recommendation. We use R to denote the universe of recommendations. – A recommendation result R = h ￾ e1, do(e1, ρ, L), dont(e1, ρ, L)
, ￾ e2, do(e2, ρ, L), dont(e2, ρ, L)
, . . . , ￾ en, do(en, ρ, L), dont(en, ρ, L)
i is a sequence of rec￾ommendations, such that R ∈ R∗ and ∀1≤i<j≤n ei 6= ej . The nature of the ordering over recommendations is kept abstract, however, we provide a possible ordering for a recommendation result in Example 1, Section 3.6. In the next section we describe how recommendations are generated by the recommendation service based on an existing event log L. 3.3 Trace Abstraction When generating log-based recommendations only those traces from the event log should be considered, which are relevant for determining the predictive infor￾mation of an enabled activity. From those traces the ones with a high degree of matching with the partial trace execution should be weighted higher than those with small or no match. To determine which log traces are relevant to provide recommendations for a given partial trace and to weight them according to their degree of match￾ing we need suitable comparison mechanisms for traces. Our recommendation service provides three different trace abstractions based on which traces can be compared, namely, prefix, set and multi-set abstraction. The prefix abstraction basically allows for a direct comparison between the partial trace and a log trace. In practice such a direct comparison is not always relevant, e.g., when the order￾ing, or frequency of activities is not important. Therefore we provide with set and multi-set two additional abstractions. They are independent of the domain context, e.g., they do not assume the process to be a procurement process or an invoice handling process [17]. Definition 6 (Trace abstraction). Let A be a set of activities, L ∈ B(A∗ ) be an event log and σ ∈ L be a trace. σp = σ denotes the prefix abstraction of σ, σs = {a | a ∈ σ} denotes the set abstraction of σ and σm = par(σ) denotes the multi-set abstraction of σ, i.e., for all a ∈ σ holds that σm(a) = par(σ)(a)