Work ow Flexibility by Deviation by means of Constraint Satisfaction Problem Solving

Abstract

This paper introduces a novel approach for exible work ow management by applying constraint satisfaction problem solving. This enables us to support work ow deviations at runtime, react to upcoming events or unpredictable circumstances, but still support the user through worklist suggestions. The developed work ow engine is completely based on declarative work ow representations, whereas procedural languages are used for work ow modeling.

Introduction

In small and medium-sized enterprises (SMEs) there is a strong demand for support concerning management of documents, business data, and processes as well as a need for supervision and control of all running and completed transactions [ 14 ]. Especially for employees who are unaware of common processes, a Process-Aware Information System (PAIS, [ 1 ]) would be of advantage, as they may pro t from guidance concerning ideal work ow execution and task suggestion. Additionally, compliance concerning standards and guidelines would be facilitated, as bene t for the enterprises. However, the use of PAISs has not yet been broadly established in SMEs. A reason for this is that current PAISs control process execution by traditional work ow engines in which work ows are prescribed without providing any exibility to deviate, if necessary [ 5, 15 ]. This is a particular problem in SMEs as their processes are only slightly standardized and weakly structured and may vary signi cantly from case to case [ 9, 17 ].

Arti cial Intelligence (AI) is a key technology for various support strategies in Business Process Management (BPM), as it allows for automated decision making and thus, facilitates the users work. Allowing exibility requires such intelligent technologies, as the user should only be guided executing a work ow and not be burdened with taking di cult decisions that could be automated. Declarative work ows are a means of implicitly o ering exibility but therefore require technologies from the eld of AI for work ow control. DECLARE [ 2 ] is a tool suite for declarative work ow modeling and enactment. Declarative models consist of constraints which de ne undesired behaviour. Constraints are then transformed to nite-state automata which allow for reasoning about work ow states. A drawback of this approach is that this transformation process is ine cient for more than about 50 constraints [ 10 ] and thus runtime support for changing circumstances is not provided. With an approach based on constraint satisfaction problem (CSP) solving we aim at achieving model changes at runtime e ciently, as constraints can simply be added or retracted without the need of a transformation. Furthermore with a combination of imperative and declarative paradigms the presented approach leads to an increased exibility.

In this paper we present an approach for exible work ow execution utilizing CSP solving to handle occurring deviations and to control worklist suggestions. First, the foundations concerning exible work ow management are sketched, followed by the introduction of our new concept for combining imperative and declarative paradigms for exible work ow execution. This approach is further described by algorithms which are based on CSP solving. The paper ends with a brief outlook on future work. 2

Foundations and Related Work

A work ow is \the automation of a business process, in whole or part, during which documents, information or tasks are passed from one participant to another for action, according to a set of procedural rules" [ 21 ]. A Work ow Management System (WfMS) supports the execution of work ows by a workow engine that interprets the process de nitions and interacts with a worklist handler, which is in charge of assigning work items to users.

Work ow Flexibility Traditional WfMS are rigid and do not allow any deviations from modeled work ows. Users feel restricted and such systems are rapidly considered as a burden. Thus, users bypass the systems, which is counterproductive for attaining the expected bene ts [ 5 ]. Consequently, PAISs that allow a work ow to exibly deviate are essential for e ciency in SMEs. Schonenberg et al. [ 16 ] distinguish between four kinds of work ow exibility: Flexibility by Design, Change, Underspeci cation, and Deviation. The rst three types require either complete knowledge about all possible work ow execution paths at design-time or demand a remodeling of the work ow at run-time. Hence, a exible reaction to sudden changing circumstances during run-time is prevented, or actions are required to manually change the process instance, which is impossible for inexperienced users. \Flexibility by Deviation is the ability for a process instance to deviate at run-time from the execution path prescribed by the original process without altering its process model."[ 16 ]. Although this approach eliminates the previously mentioned disadvantages, little research exists on how to implement this approach. Only the system FLOWer [ 3 ] implements this idea to a limited extent by allowing the user to skip, undo, or redo a task or to insert a new task, but still the user has to intervene manually to obtain exibility. Work ow Modeling Paradigms Work ow modeling paradigms range from imperative (procedural) to declarative [ 6 ]. Imperatively modeled work ows explicitly specify all possible allowed execution paths, for example using a owbased modeling language such as BPEL ([ 4 ]). Here, the control ow of tasks as well as the related ow of data items is modeled, which results in a high complexity and a huge modeling e ort. Declarative work ows, however, de ne forbidden behavior and states of the work ow. Imperative work ows only describe a subset of valid procedures, while declarative constructs describe speci c undesired states, leading to the acceptance of every other state [ 11 ] and thus, implicitly providing exibility concerning work ow execution.

Current declarative work ow approaches such as DECLARE [ 2 ], formally base on Linear Temporal Logic formulae representing constraints, which are further transformed into nite-state automata, for constraint validation, as workow engine and for worklist handling. Though there is a di erentiation between mandatory and optional constraints, and optional ones may be violated, a possibility to retract constraints is not speci ed and therefore no unforeseen situations can be handled exibly. The concept of DCR graphs [ 8 ] is described as o ering more exibility, but also has no possibility to restore consistency after deviations. In later work Maggi et al. [ 10 ] developed an approach, Mobucon, based on colored automata, with the ability to detect deviations and in addition to support continuously through various strategies. A drawback of this approach is that strategies need to be determined beforehand, and cannot be changed during runtime, as the construction of a new automaton would take too long [ 10 ]. Algorithms developed by Westergaard [ 20 ] also solve this issue with e cient runtime modi cations, e.g. models with up to 50 constraints are handled in seconds.

Our approach also aims at achieving e cient automated runtime modi cations and thus requires the ability to react adequately to deviations, even to undesired situations. A main di erence between related work and our approach is that our work ow control bases on the interpretation of incoming documents and their semantic information. The identi cation of semantic information has a signi cant impact on work ow control and can be easily de ned as logical constraints. Furthermore constraints can be added or retracted ad-hoc, without the need of a time-consuming recompilation of the model. Therefore we regard the identi cation of executable tasks as constraint satisfaction problem. 3

Concept of the Work ow Engine

With the presented concept we aim to increase the acceptance of users, as the presented concept does not prescribe, but still guides, if needed. Additionally, transactions are logged for control and monitoring purposes. The implementation of the approach of Flexibility by Deviation as presented in this paper is embedded in the SEMAFLEX1-architecture [ 7 ], which semantically integrates exible work ow management with knowledge-based document management and will be developed further in the SEMANAS project. An important characteristic is that the information about task enactment can either result from a user interaction, e.g. a manual selection of a task being performed, or due to upcoming documents, which are analyzed automatically and mapped to a certain task, whose 1 SEMAFLEX is funded by Stiftung Rheinland-Pfalz fur Innovation, grant no. 1158 enactment is derived subsequently. These logged task enactments construct the actually conducted work ow as a sequence of activities that have been performed. While the work ow engine proposes tasks which should be done next, the user is not forced to follow these suggestions. In principle, the user is able to do what s/he wants and in which order s/he wants. S/he can either follow the tasks in the worklist, suggesting the standard course of action, or do something else and upload documents created as a result of what s/he did. Through both, explicitly completing a task and uploading documents, the actual work ow is identi ed and recorded. Progress in turn a ects the worklist handling, including detected deviations. 3.1

Combination of Imperative and Declarative Paradigms

For a suitable representation of the work ows concerning this concept, we explicitly di erentiate between modeled work ow, de jure work ow, and executed work ow, de facto work ow [ 1 ]. The de facto work ow is an actually enacted instance derived from a de jure work ow. Thus, it stores the actually conducted transactions and thus might deviate from the de jure work ow.

In our approach the de jure work ow is modeled procedurally, as it is more intuitive and comprehensible than declaratively modeled work ows [ 12 ]. The work ow engine, however, is completely based on a declarative representation, as this paradigm implicitly o ers exibility concerning execution. To reach a maximum of exibility, we transform the de jure work ow into declarative constraints, which are used to control the suggested execution order of tasks, but which are not regarded as mandatory and consequently might be violated. Hence, the de jure work ow is only considered as guidance, but deviations are tolerated. Nevertheless, some deviations are critical and should never occur, considering e.g. compliance or safety aspects. For this reason, additional mandatory constraints can be modeled manually, to explicitly specify invalid work ow states. Those are possibly connected with a severity speci cation, a warning message or even a proposed corrective measure, in case the constraint is violated. Such mandatory constraints can refer to the execution order of the tasks within a de jure work ow or they could be global constraints specifying order constraints across classes of work ows. Of course those mandatory constraints might actually be violated by the user, as the work ow engine never prescribes an activity and thus is not able to actively prevent violations. Nevertheless, the violation of constraints (including the mandatory ones) can be detected. Depending on the kind of constraint violation the work ow engine shall be able to react adequately. If a non-mandatory constraint is violated, the deviation is not considered as critical, but the work ow engine must reason about the next task to propose. If a mandatory constraint is violated, a warning is issued or a corrective measure is performed according to what is speci ed for the constraint. 3.2

Declarative Work ow Representation

For the declarative work ow representation, we utilize ve di erent constraint types of the DECLARE language [ 2 ], which countervail possible deviations: { Precedence(ta; tb): Task tb can only be executed after ta. { Response(ta; tb): Task ta requires the enactment of tb. { Existence(ta): Task ta is mandatory. { Not Co-Existence(ta; tb): Task ta and tb exclude each other.

{ Absence(ta; x): Task ta can only be executed x times.

Precedence and Response prevent undesirable skipping, concerning previous or subsequent tasks. Existence contradicts the undoing of a task. Redoing and creating additional instances of a task are intercepted by the constraint Absence. Not Co-Existence avoid invoking undesired task enactments.

Preventing the user from constraint violations in our case can only be achieved, if the user manually chooses tasks from the worklist, as only such tasks are proposed that lead to a valid work ow state. As non-mandatory constraints might be violated, the worklist could consider tasks that contradict these constraints but with lower priority. Mandatory constraints should never be disregarded. Worklist handling is easy for procedurally modeled work ows, if no deviations are possible. However, if a deviation occurs, one would not be able to suggest an appropriate further proceeding. Constraints suit this situation perfectly, as even if one is violated, it might be retracted, and still valid suggestions can be computed with the help of remaining constraints. How valid task suggestions are identi ed, will be explained in the following section.

A prerequisite for the presented enactment approach is that each construct of the de jure work ow, modeled imperatively, is automatically transformed into corresponding declarative expressions. 3.3

Transformation into Declarative Constructs

We consider the essential structures of imperative modeling languages on the basis of Weske [ 19 ]. The transformation rules, as described in Tab. 1, are de ned analogously to [ 18 ], who in contrast uses Relation Algebra as formal speci cation language. The resulting constraints are used for validating upcoming enactment states of the work ow and for proposing tasks enabled for execution. The following section describes the algorithm that computes possible task suggestions on the basis of these declarative constraints. 4

Worklist Handling by means of Constraint Satisfaction

Problem Solving

According to Russell and Norvig [ 13 ] a constraint satisfaction problem (CSP) is de ned by a set of decision variables X = fX1; X2; :::; Xng and a set of constraints C = fC1; C2; :::; Cmg. Each decision variable has a domain Di, which is a nonempty set of possible values for Xi. A constraint Cj is a relation over a subset of the variables fXk; :::; Xlg, specifying the set of combination of allowed values. An assignment of values to some or all of the variables is called state of the problem, which is denoted as consistent, if it does not violate any constraint. If values are assigned to every variable, the assignment is named complete. A consistent and simultaneously complete assignment is called solution. In the following we formulate the problem of selecting the next tasks for execution in case of deviation from the de jure work ow as a constraint satisfaction problem. 4.1

Application of CSP Solving

The CSP solving algorithm is applied during work ow execution at the start of each work ow and after each task enactment. The initial state for the algorithm is a partially completed work ow, the de facto work ow, and its corresponding ideal course of events, the de jure work ow. The desired output is the set of tasks, called worklist, that can be enacted next without violating constraints.

To utilize CSP solving for worklist handling, we regard the work ow tasks as decision variables X = T . For each task ji 2 J = fj0; :::; jn 1g of the de jure work ow, a variable tji is created and added to T . Subsequently, T is supplemented with one single variable tend, to be able to determine whether the work ow has completed. The elements of this set may vary while the work ow progresses (see Sect. 4.3). The assignment of values to tasks represents a sequential order of all tasks, including not only already executed tasks, but also possible future executions of tasks. Thus, a valid order, determined by ascending integer values, of tasks is calculated. As the only thing of interest is, which task may be executed next at a speci c point in time, it does not matter if any other tasks might be or have been executed in parallel. Consequently, the domain for each decision variable is a set of integer values Di = f0; 1; : : : ; ng, with n as the number of tasks extracted from the de jure work ow including the additional variable tend.

As the assignment represents a sequential execution order of all tasks, the rst given constraint (see (1)) states that each assigned value of a decision variable is di erent from all others. Thus, only a bijective mapping of domain values to decision variables is a solution to the CSP.

C = falldi erent (T ) ; ti = ci; : : : ta < tb; ta < tend; (tend < ta) _ (ta < tb) ^ (tb < tend); (tend < tb) _ (tend < ta); n X f (ref (ti) ; ta) < x; i=0 (si = a1) ) (tend < t2); ^ (si = a2) ) (tend < t1)g (for de facto)

P recedence(ta; tb)

Response(ta; tb)

Existence(ta)

N ot Co-Existence(ta; tb) (6) Absence(ta; x)

(1) (2) (3) (4) (5) (7) (8) (9) and f (ref (ti) ; ta) = with ref (ti) returning the id of the referenced object of the de jure work ow (1 if ref (ti) = ta

0 otherwise

Second, as we apply the CSP at a speci c point in time during execution of the work ow, some tasks are already enacted and therefore the respective variables have a xed assignment ci, which is a constant value specifying the sequential execution position in the de facto work ow (see (2)). All additional constraints either result from the transformation of imperatively modeled work ow to declarative language constructs or originate from manually modeled mandatory constraints. Each type of constraint has a corresponding formal de nition to be used in the CSP solving algorithm (see (3) to (7)). As some constraint violation explicitly depends upon work ow completion, tend is used to determine the termination of a work ow. This is necessary to assert a mandatory enactment of a task, a required execution of a task after a certain one, or even to assure that some tasks have not been conducted. Considering the solution of the CSP every task with a higher integer assigned than tend is regarded as not enacted.

Due to the construction of the CSP, we are also able to in uence the control of the work ow on the basis of semantic information. Control- ow nodes are additionally considered as constraints to further automate the control process. On this basis tasks are excluded from enactment proposals. For each xor or loop construct (cf. Fig. 1) two constraints are included (see (8, 9)). With si representing a decision variable, which either takes a1 or a2 as value, we are able to derive which path in the work ow should be followed. For work ow control the execution of the oppositional path is prevented, e.g. if the information of si is known to be a1, task t2 should not be enacted (tend < t2).

Furthermore, considering the importance of data nodes for the presented approach, additional constraints are generated on the basis of data dependencies. For example, if data node d1 is output of task t1 and input of t2, a constraint P recedence(t1; t2) is inserted in the set of constraints, as it is necessary to enact task t1 to subsequently process d1 with t2.

Table 2 shows an example transformation from procedurally modeled workow to constraints to logical formulae, which are then used by the algorithm. To identify all tasks that might be enacted next, a solution to the presented CSP, on the basis of the previously explained generated constraints, is searched for (cf. Algo.1). The algorithm takes the sets T and C as input for CSP Solving, whereas the domains Di are derived from the size of T . The set F , also used as input, represents the de facto work ow and contains the variables from T , whose referenced tasks have been enacted. As output the variable result is introduced, which represents the set of tasks that might be enacted next. The value of the expected tasks, denoted here as current, is determined by the size of F , as this is the position which will be occupied by a task executed next. If every solution

Declarative constraints Logical formulae for the CSP Precedence(A,B), A < B ^ A < C^ Precedence(A,C), (B < D _ C < D)^ Precedence(B,D) or (End < B _ End < C)^ Precedence(C,D), (XY = yes) ) (End < C)^

Not Co-Existence(B,C) (XY = no) ) (End < B)

Algorithm 1: Determination of tasks which might be executed next to the CSP would be computed, this would result in redundant and unnecessary computations. To accelerate proceedings, we apply the CSP solving algorithm only once for each decision variable that has not been assigned a value yet, thus, has not been executed. If the CSP solving algorithm nds a solution, this task might be executed next and therefore is appended to result. If no solution is found, the user must not execute the task next and thus, it is not proposed. 4.3

Deviation Detection

If a task enactment occurs, variable assignments are updated and constraints are validated to analyze the state of the work ow and possibly restore consistency. Algorithm 2 illustrates this procedure. As input, the enacted task jn of the de jure work ow is received. First, the length of the de facto work ow needs to be determined, which identi es the assigned value to the variable of the currently enacted task within the CSP. The corresponding variable tjn is included in the de facto work ow F , and constraints are extended with the value assignment of current to tjn . As this task enactment might result in a constraint violation, and consequently in an inconsistent work ow state, all constraints need to be validated. If no solution is found, the violated constraint needs to be identi ed and retracted from C to restore consistency. In case a mandatory constraint is violated, the respective warnings and corrective actions are triggered. After each task enactment the constraint set is simpli ed in order to prevent unnecessary computations. Based on the value assignments due to the de facto work ow, which will never change for a work ow instance, some constraints will always resolve to true, while other parts always resolve to false, even without constraint violations, e.g. disjunctive associated propositions. Assuming that the constraint set is available in conjunctive normal form C = c1 ^ ::: ^ cn, clauses ci are linked conjunctively and each clause represents a disjunction of literals ci = l1 _ ::: _ ln. The literals mostly result from the transformation of declarative work ow constructs to logical representations and thus, relate two tasks with the ordering "<". Other literals may be equations, such as t1 = 0, depicting the de facto work ow, or alldi erent(T) due to the construction of the CSP. The

Input : Task jn 1 current = jF j; 2 F = F [ ftjn g; 3 C = C [ ftjn = currentg; 4 if !validateConstraints(C) then 5 retractViolated(); 6 end 7 simplifyConstraints(tjn );

Algorithm 2: Deviation Detection literals of interest for CSP simpli cation are the rst ones. If a task enactment of task ti occurs, all clauses with ti on the left side (e.g. ti < tj ) in one of the literals are withdrawn, as this clause will resolve to true in any case. Furthermore single literals, which contain ti on the right side, e.g. tj < ti, can be retracted. Those will never be ful lled, but the remaining literals in the clause have to be.

One impact of this simpli cation strategy after each task enactment is that violated constraints can be easily determined. A clause consisting of a single literal, e.g. ti < tj , where the currently enacted task tj is on the right side, is violated, as ti has not yet been enacted, as otherwise the clause would have been withdrawn from the constraint set previously. 4.4

Extension of the CSP for Loop Patterns

Until now the approach is limited to a singular execution of tasks and not incorporating loop constructs or considering deviations like redoing a task. Thus, an algorithm is needed which alters the input sets for Algo. 1 in case of these previously mentioned scenarios. The trigger for this processing (cf. Algo. 3) is an enactment of task jn of the de jure work ow.

To di erentiate between individual task instances in case of a repeated enactment, the decision variables in T are extended with a second index variable l, e.g. t(jn;l), denoting the numbering of task instances referencing one single task, here jn, of the de jure work ow. This second index also simpli es the validation of the constraint Absence(ta; n), because n might be compared to the second index l of the tasks that have already been executed. At rst, the variable t(k;l) corresponding to task jn has to be found. The following condition checks whether the enacted task was the rst of a loop construct. If so, the CSP is extended considering a possible further execution within the loop. Thus, a new decision variable t(jm;l+1), for each task jm in the loop, is included with an increased numbering variable (l + 1). Domains have to be expanded and constraints considering the new loop tasks have to be incorporated. 5

Conclusion and Future Work

In this paper we presented a novel concept for work ow exibility by deviation that combines procedural and declarative work ow paradigms. Upcoming doc

Input : Task jn 1 nd t(k;l) such that k = jn and t(k;l) 2 T n F ; 2 if isF irstT askInLoop(jn) then 3 foreach jm 2 loop do 4 T = T [ ft(jm;l+1)g, with m = jT j; 5 foreach Di 2 D do Di = Di [ fjT j 1g; 6 addConstraints with usual loop constraints; 7 end 8 end

Algorithm 3: CSP extension uments and extracted semantic information are used to determine the current state of the work ow and for control purposes. In order to react to deviations and still propose the best way of proceeding with the work ow, constraint satisfaction problem solving is applied. Future work will focus on a detailed elaboration of the single algorithms and possible improvements to achieve better results. Subsequently, the implementation will be evaluated against related approaches. Additionally, the concept will be developed further, as the work ow designer should be granted more freedom to choose how strict or exible the constraints should be treated for worklist handling and, furthermore, which and how countermeasures could be speci ed.

References

1. van der Aalst , W.M.P. : Business Process Management - A Comprehensive Survey . ISRN Software Engineering 2013 , 1 { 37 ( 2013 )

2. van der Aalst , W.M.P. , Pesic , M. , Schonenberg , H.: Declarative work ows: Balancing between exibility and support . Computer Science - R&D 23 ( 2 ), 99 { 113 ( 2009 )

3. van der Aalst , W.M.P. , Weske , M. , Grunbauer, D.: Case handling: a new paradigm for business process support . Data Knowl. Eng . 53 ( 2 ), 129 { 162 ( 2005 )

4. Andrews , T. , Curbera , F. , Dholakia , H. , Goland , Y. , Klein , J. , Leymann , F. , Liu , K. , Roller , D. , Smith , D. , Thatte , S. , Trickovic , I. , Weerawarana , S. : Business Process Execution Language for Web Services, Version 1.1. Tech. rep., BEA Systems , International Business Machines Corporation, Microsoft Corporation ( 2003 )

5. Dadam , P. , Reichert , M. , Rinderle-Ma , S.: Prozessmanagementsysteme - nur ein wenig Flexibilitat wird nicht reichen . Informatik Spektrum 34 ( 4 ), 364 { 376 ( 2011 )

6. Fahland , D. , Lubke, D. , Mendling , J. , Reijers , H.A. , Weber , B. , Weidlich , M. , Zugal , S. : Declarative versus Imperative Process Modeling Languages: The Issue of Understandability . In: Enterprise, Business-Process and Information Systems Modeling , 10th International Workshop, BPMDS 2009, and 14th International Conference, EMMSAD 2009 , held at CAiSE 2009 , Amsterdam, The Netherlands, June 8-9, 2009 . Proceedings. pp. 353 { 366 ( 2009 )

7. Grumbach , L. , Rietzke , E. , Schwinn , M. , Bergmann , R. , Kuhn , N.: SEMAFLEX - Semantic Integration of Flexible Work ow and Document management . In: Krestel, R. , Mottin , D. , Muller, E. (eds.) Proceedings of the Conference "Lernen , Wissen, Daten, Analysen" , Potsdam, Germany, September 12-14 , 2016 . CEUR Workshop Proceedings , vol. 1670 , pp. 43 { 50 . CEUR-WS.org ( 2016 )

8. Hildebrandt , T.T., Mukkamala , R.R. : Declarative Event-Based Work ow as Distributed Dynamic Condition Response Graphs . In: Proceedings Third Workshop on Programming Language Approaches to Concurrency and communication-cEntric Software, PLACES 2010 , Paphos, Cyprus, 21st March 2010 . pp. 59 { 73 ( 2010 )

9. Ho mann, D.: Schlanke Formen des Geschaftsprozessmanagements Das richtige BPM-Rezept ( February 2013 ), http://www.it-zoom.de/it-mittelstand/e/dasrichtige-bpm-rezept- 5287 /

10. Maggi , F.M. , Montali , M. , Westergaard , M., van der Aalst , W.M.P. : Monitoring Business Constraints with Linear Temporal Logic: An Approach Based on Colored Automata . In: Business Process Management - 9th International Conference, BPM 2011 , Clermont- Ferrand , France, August 30 - September 2 , 2011 . Proceedings. pp. 132 { 147 ( 2011 )

11. Pesic , M.: Constraint-based work ow management systems: shifting control to users . Ph.D. thesis , Technische Universiteit Eindhoven ( 2008 )

12. Pichler , P. , Weber , B. , Zugal , S. , Pinggera , J. , Mendling , J. , Reijers , H.A. : Imperative versus Declarative Process Modeling Languages: An Empirical Investigation . In: Daniel, F. , Barkaoui , K. , Dustdar , S. (eds.) Business Process Management Workshops - BPM 2011 International Workshops , Clermont-Ferrand, France, August 29 , 2011 , Revised Selected Papers , Part I. Lecture Notes in Business Information Processing , vol. 99 , pp. 383 { 394 . Springer ( 2011 )

13. Russell , S.J. , Norvig , P. : Arti cial Intelligence - A Modern Approach (3 . internat. ed.). Pearson Education ( 2010 )

14. Saam , M. , Viete , S. , Schiel , S. : Digitalisierung im Mittelstand: Status Quo, aktuelle Entwicklungen und Herausforderungen ( August 2016 )

15. Schlecht , M.: Prozessmanagement in der Cloud . ERP Management 4/2013: Betriebsformen moderner Systeme 3 , 33 { 36 ( 2013 )

16. Schonenberg , H. , Mans , R. , Russell , N. , Mulyar , N., van der Aalst , W.M.P. : Process Flexibility: A Survey of Contemporary Approaches . In: Advances in Enterprise Engineering I, 4th International Workshop CIAO! and 4th International Workshop EOMAS , held at CAiSE 2008 , Montpellier, France, June 16-17, 2008 . Proceedings. pp. 16 { 30 ( 2008 )

17. Supyuenyong , V. , Islam , N. , Kulkarni , U. R.: In uence of SME characteristics on knowledge management processes: The case study of enterprise resource planning service providers . J. Enterprise Inf. Management 22 ( 1 /2), 63 { 80 ( 2009 )

18. Wedemeijer , L. : Transformation of Imperative Work ows to Declarative Business Rules . In: Shishkov, B . (ed.) Business Modeling and Software Design - Third International Symposium, BMSD 2013 , Noordwijkerhout, The Netherlands, July 8 - 10 , 2013 , Revised Selected Papers. Lecture Notes in Business Information Processing , vol. 173 , pp. 106 { 127 . Springer ( 2013 )

19. Weske , M. : Business Process Management: Concepts , Languages, Architectures. Springer ( 2007 )

20. Westergaard , M. : Better Algorithms for Analyzing and Enacting Declarative Workow Languages Using LTL . In: Business Process Management - 9th International Conference, BPM 2011 , Clermont- Ferrand , France, August 30 - September 2 , 2011 . Proceedings. pp. 83 { 98 ( 2011 )

21. Work ow Management Coalition: Work ow Management Coalition Terminology & Glossary ( February 1999 )