Modeling Business Objectives for Business Process Management
Transcript Of Modeling Business Objectives for Business Process Management
Modeling Business Objectives for Business Process Management
Matthias Lohrmann and Manfred Reichert
Ulm University, Databases and Information Systems Institute, {matthias.lohrmann,manfred.reichert}@uni-ulm.de
Abstract. For application scenarios such as the management of business process variants or business process quality, business objective models assume the role of formal requirements definitions as in software engineering. However, effective concepts in this area still constitute a gap in the presently available array of business process management methods. To address this issue, this paper develops and shortly evaluates a refined business objective modeling approach. Our approach builds on use case-based effectiveness criteria, and on insights gained from assessing the state of the art. It derives required constructs and interrelations from application scenarios, and integrates these into a business objective meta-model. As an initial validation of our concept, we model a sample scenario and match the results against effectiveness criteria.
Key words: Business Objectives, Business Goals, Business Process Modeling, Business Process Quality
1 Introduction
Definitions for the term business process range from business process reengineering approaches [1, 2] to trade associations [3] and current business process management (BPM) research [4]. They generally comprise a notion of business goals or business objectives, which can be viewed as an integral aspect reflecting the utilitarian nature of business processes. It is therefore interesting that formal modeling of business objectives is not covered by common business process modeling approaches such as BPMN [5], EPCs [6] or Workflow Nets [7].
To further illustrate the potential benefits of concise business objective modeling, we consider its possible use cases. In general, business objective models could assume the role of a formal requirements definition for business process design, implementation and enactment. Accordingly, application scenarios and benefits are generally comparable to broader requirements engineering [8, 9].
From an a priori perspective, business objective models add a layer of abstraction to business process models. They allow discussing and documenting business objectives independently from a concrete implementation, and assessing the effectiveness of implementation options. From an ex post perspective, they can be used to determine whether a business process instance (or a set
2
Matthias Lohrmann and Manfred Reichert
of instances) has terminated in a state being consistent to the organization’s business targets. In addition to these general use cases, we point out three more specific exemplary scenarios that are closely related to present directions of BPM research: automated derivation of business process models, management of business process variants, and business process quality management.
Scenario 1 (Automated Derivation of Core Business Process Models). An available business objective model would comprise formalized information on the things a respective business process should create or alter including decision criteria, ordering constraints, etc. On that basis, it would be possible to formally derive minimum control flow implementation requirements. In addition, it would be possible to integrate the approach with process mining techniques [10]. For instance, real-world cases might be used to analyze the probability of control flow decision criteria given in a business objective. This would allow for automated or even continuous control flow optimization.
Scenario 2 (Management of Business Process Variants). The management of business process variants has emerged as an important BPM issue [11]. However, determining whether two process instances are variants of the same business process remains a “missing link” in this respect, especially when considering the mining of process variants or reference processes [12], or the refactoring of model repositories [13]. Formally modeling business objectives could contribute to closing this gap, as it would enable to assess the “equivalence” of process variants with respect to a business objective.
Scenario 3 (Business Process Quality Management). Business process quality management constitutes another emerging area of BPM research. In [14], a definition framework in this regard was developed. The concept of efficacy, i.e., whether a business process achieves its business objective, is crucial in this respect. Thus, formal modeling of business objectives constitutes an important prerequisite to effectively assess business process quality in design, implementation and enactment.
Scenario 4 (Subject-oriented Business Process Management). Subject-oriented business process management (S-BPM) constitutes an approach to address critical practical issues in BPM adoption, thereby significantly broadening its appeal [15]. The concept is based on shifting the paradigm of BPM away from formalizing tasks to be executed to the roles and interactions of subjects or stakeholders. As this potentially takes out some of the implicit formality of, e.g., strict control flow, it is all the more important to employ concise business objective models to ensure effectiveness, i.e. making sure that a process still achieves what it should.
Our research has shown that present approaches to business objective modeling do not yet effectively support the application scenarios set out above. This paper therefore seeks to develop a refined solution which is methodologically well-founded as well as readily applicable in future research and for practical purposes. The remainder of the paper is structured as follows: Section 2 presents our methodology including process examples to illustrate our ideas, basic terminology, and effectiveness criteria to evaluate results. Sections 3, 4, and 5 implement our methodology, from a review of available approaches to a refined business objectives meta-model. Section 7 concludes the paper and gives an outlook on future research.
2 Methodology and Preliminary Considerations
A business objective model constitutes a goal-bound artificial construct. We therefore apply the principles of design science [16, 17]. Accordingly, our methodology consists of the following steps:
1. Define effectiveness criteria to assess the utility of design artifacts in the field of business objectives modeling (cf. Section 2.3).
Modeling Business Objectives for Business Process Management
3
2. Assess the state of the art based on the defined effectiveness criteria to determine gaps and obtain pointers towards a refined solution (cf. Section 3).
3. Build required terminology for business objectives based on effectiveness criteria and research into available approaches (cf. Section 4).
4. Build a meta-model for business objectives (cf. Section 5). 5. Evaluate our solution with respect to effectiveness criteria (cf. Section 6). 6. Discuss implications and further steps to leverage our results (cf. Section 7).
The remainder of this section presents two sample business processes we use to illustrate and evaluate our results, discusses required preliminary terms, and develops effectiveness criteria to evaluate present approaches as well as our work.
2.1 Sample Processes
Our first sample process stems from the field of accounting: invoice checking and approval constitutes a typical example of an administrative process which is often supported by workflow management systems. 1
To ensure that our concepts are also applicable to domains where workflow applications are not as common, we include a second sample process from the field of healthcare. Figures 1 and 2 show the models of the two sample processes in terms of BPMN [5] flow charts.
Example 1 (Sample Process A: Invoice Checking and Approval). The business process starts with the receipt of a supplier invoice (activity A1). The invoice is then compared to the respective purchase order (A2). If deviations exist, these are subject to approval. In practice, this is often the case when, for instance, price data have not been maintained or when no purchase order has been entered into the ERP system. If the deviation is approved (A3), the purchase order is created or adapted (A4). Otherwise, the invoice is declined (A6, A7). In the next step, the invoice is matched against goods receipt (A5) and, depending on the result, either declined (A6, A7) or passed to the next check, which is based on the invoice value. For a value of more than 5,000, senior management approval (A8) is required. If this is granted, the invoice may finally be approved (A9).
Example 2 (Sample Process B: Medical Examinations). In our alternate example from the healthcare field, a medical examination A is performed (B1). Based on its result, a drug is applied (B2) and a second examination B (B3) is performed or not. A third examination C, which may only be carried out once examination A is completed, should follow in each case (B4). Thereafter, another drug is applied depending on the result of examination C (B5) and the age of the patient. In parallel, further steps are performed depending on the results of examinations A and B: First, the existence or non-existence of condition X is noted dependent on the result of examination C (B6, B7). Then, a fourth examination D is performed (B8). After completing examination D, application of a drug is required (B9).
2.2 Basic Terminology
Business processes constitute artifacts in the sense of design science [16] which operate within an affecting and affected outer environment. The outer environment of a business process consists of target artifacts and resources, i.e. things
1 Incoming invoices processing was used to illustrate the concept of business process reengineering by both Davenport and Hammer [1, 2].
4
Matthias Lohrmann and Manfred Reichert
A1: Receive invoice
A2: Match purchase
order
Invoice Symbols
Activity
XOR Gateway (Split / Join) Start Event (Message-based)
End Event
Target Artifact
Not ok
A3: Approve deviation
A5: Match goods receipt
Invoice value > 5,000
A8: Obtain senior
approval
A4: Adapt purchase
order
Purchase order
Not approved
Not ok
Approval declined
A6: Contact supplier
A9: Approve invoice
Invoice
Invoice A7:
Decline invoice
Fig. 1. Sample Process A: Invoice checking and approval
C1: Execute examination
A
Results A
Result A > 50
C2: Apply drug I
C3: Execute examination
B
Application I
Symbols OR Gateway (Split /Join)
Results B
C4: Execute examination
C
Result C > 100 AND Age > 50
Results C
Result A > 100 OR Result B
> 100
Result C <=100
Condition X
C6: Note condition X
existent
Condition X
Result C > 100
C7: Note condition X nonexistent
C5: Apply drug II
Application II
C8: Execute examination
D
C9: Apply drug III
Results D
Application III
Fig. 2. Sample Process B: Medical examinations
the process strives to create and alter, and things required to properly do so. Note that this perspective differs in some regards from the classic BPM concepts of process input and process output as it includes things usually not considered (e.g. capital goods). This topic was discussed in more detail in [14].
In the field of BPM, business objectives represent the targets an organization aims to achieve with a business process. As illustrated in Example 3, this can be understood on a strategic, collective operational or transactional level.
Example 3 (Semantic Business Objective Levels). As another exemplary business process, consider the handling of job applications in an enterprise. On a strategic level, the business objective of this process may be understood as providing the organization with the right “human resources”. On a collective operational level, the business objective may be understood as properly handling the overall occurring cases of job applications. Depending on the required service level, the business objective may, for instance, be fulfilled if 90% of cases are managed correctly. On a transactional level, it may be understood as properly handling an individual application.
For the purpose of business objectives modeling, we define the term business objective on the transactional level to achieve consistency with common business process modeling approaches: In business process modeling, models are generally defined on a process instance [3] level without considering the cardinality of cases or instances. This means that a task that occurs many times for the business process, but one time per process instance is modeled as an individual activity, not as a set of activities.
Modeling Business Objectives for Business Process Management
5
Moreover, remember that an affecting environment may determine what actually needs to be induced to fulfil a business objective, for instance when considering decision processes (cf. Example 4).
Example 4 (The Affecting Environment of Business Objectives). Again, consider the job application process from Example 3. In this case, the business objective cannot be achieved by simply approving or disapproving an application. Rather, the respective hiring criteria are to be considered. Thus, they constitute the affecting environment of the business objective. As another example, consider medical treatments. In many cases, tests are required to find out which drugs are required. In this case, the test results are part of the affecting environment of the business objective.
Note that, when considering business objective levels as well as the affecting environment, the organizational target as the business objective on strategic level may differ from business objectives on lower semantic levels. This occurs when the affecting environnment restrains the business process from achieving the original organizational target (cf. Example 5). In other words, there may be states of the affecting environment where the business objective of the process is fulfilled while the corresponding organizational target has not been achieved.
Example 5 (Business Objective Levels and the Affecting Environment). When handling incoming job applications, the strategic organizational target will be to fill the respective positions. However, the business objective on more operational levels may well pertain to decline an applicant if her qualifications (as part of the affecting environment) are not sufficient.
In summary, this leads us to the following basic definition for business objectives to be further elaborated in our modeling approach:
Definition 1 (Business Objective). A business objective in the sense of business process management constitutes a refinement of organizational targets to the transactional level. It pertains to an affecting and affected environment. The affecting and affected environment represent the things to be considered and the things to be manipulated to achieve the business objective. The business objective relates each state of its relevant affecting environment to a set of aspired states of the affected environment.
2.3 Effectiveness Criteria
Considering the scenarios lined out in Section 1, business objective models as requirements definitions for business processes will generally be used to
– determine what needs to be done to achieve a business objective (e.g., as a starting point for structured business process design, or as in Scenario 1 from Section 1),
– assess whether a modeled business process enables to achieve its business objective (e.g., to evaluate design options, or as in Scenario 2), and
– assess whether a concrete business process instance has actually achieved its business objective (e.g., in testing, or as in Scenario 3).
Accordingly, the notion of an achieved function reflecting whether an aspired state of the affecting and affected environment of a business objective is reached is central to business objectives modeling.
Recapitulating the terms introduced in Section 2.2, business objectives are achieved by propagating target artifacts to an aspired state. However, which
6
Matthias Lohrmann and Manfred Reichert
SR1 SR2 SR3 UC1 UC2 UC3
Consideration of the affecting environment: Whether a business objective is achieved or not must be determined in terms of target artifacts and additional properties of the outer environment; e.g., in Sample Process A (cf. Example 1), the approved or disapproved invoice as a target artifact and the defined conditions for invoice approval as additional properties of the outer environment.
Varying target environment: The set of target artifacts to be created or altered as well as the concrete operations to be carried out on them may vary; e.g., in Sample Process A (cf. Example 1), the purchase order may have to be adapted or not, but the invoice must always be approved or disapproved.
Order constraints: There may be constraints regarding the order in which the activities of a process need to be executed in conformance with the business objective. Consider, for instance, Sample Process B from Example 2: drug application and examinations must occur in a specific order. It is important to note that these constraints actually represent constraints with respect to target artifacts manipulation, because, by definition, executing activities cannot constitute a business objective.
Semantic interdependencies: The approach should be apt to transparently capture semantic interdependencies between elements of the outer environment like mutual exclusivity or correlation. As an example for mutual exclusivity, consider the approval or disapproval of invoices in Sample Process A from Example 1 (cf. “pragmatic quality” in the sense of comprehension in [18]).
Model compaction: The approach should lead to a compact result in the sense of avoiding unnecessary content which might “hide” the relevance of model elements. For instance, in Sample Process A, it would be obstructive to model the effect of senior management approval for invoices below a value of 5,000 (cf. “semantic quality” in the sense of validity or relevance to the problem in [18]).
Knowledge externalisation: The approach should leverage implicitly available knowledge of the modeler (cf. “physical quality” in the sense of externalisation in [18]).
Table 1. Effectiveness Criteria for Business Objective Modeling Approaches
target artifacts need to be created or altered, and which states are considered as aspired may depend on other elements of the affecting environment.2 Thus, business objectives cannot be recorded solely in terms of attributes of targets artifacts, but in terms of a set of consistency rules to be satisfied in respect to the entire environment. This set of rules must be complete and free of overlaps to ensure conformance can be assessed for each state of the outer environment.
Table 1 summarizes effectiveness criteria towards business objectives modeling. The semantic requirements SR1 to SR3 are based on the issues discussed above. They reflect the semantic content an approach needs to address to properly model business objectives. In addition, an effective modeling approach will also fulfill usability criteria UC1 to UC3 to support both modelers and users. The usability criteria are based on the considerations on model quality in [18]. Since we work on a meta-model level instead of the model level addressed in [18], we place special regard to the quality types of “physical quality”, “semantic quality” and “pragmatic quality”.
2 Note that the affecting environment of a business objective may differ from the affecting environment of an associated business process – the affecting environment of an efficacious business process will encompass, but possibly not be limited to, the affecting environment of its business objective (cf. [14]).
Modeling Business Objectives for Business Process Management
7
3 State of the Art
Models for business objectives or goals3 have been proposed by Kueng and Kawalek [19], Neiger and Churilov [20], Soffer and Wand [21], and Lin and Sølvberg [22]. Markovic and Kowalkiewicz [23] proposed a business goal ontology as part of the SUPER project on semantic BPM (cf., e.g., [24]). For comparison, we include an approach by Engelman et al. towards goals modeling in enterprise architecture. Table 2 matches the approaches against semantic requirements SR1 to SR3. For reasons of brevity, usability criteria UC1 to UC3 are not considered.
Evaluation against semantic requirements (cf. Table 1)
Source / focus
Kueng and Kawalek [19]: Goals-based modeling, design evaluation
Neiger and Churilov [20]: “Value-focused thinking” to structure objectives
Soffer and Wand [21]: Formalizing processes’ contribution to “soft goals”
Lin and Sølvberg [22]: Goal ontology for semantic annotation in distributed environments
Markovic and Kowalkiewicz [23]: Integrating goals into business process modeling
Engelsman et al. [25]: Enterprise architecture goals modeling language
SR1
Not fulfilled: No formal measurable definition of goals
Not fulfilled: No formal measurable definition of objectives
Not fulfilled: Business goals as any possible process termination state, goal achievement only pertains to target artifacts
Partially fulfilled: Goals are seen as states of activities or artifacts, but no specification of respective artifact states
Not fulfilled: No concise definition of when a goal has been achieved
Not fulfilled: Hard goals concept, but no formal notion of goal achievement
SR2
Not fulfilled: Goals are discussed on an abstract level only
Not fulfilled: “Functional objectives” on a more abstract level
Partially fulfilled: Implicitly considered: only one relevant process path required per target artifact
Not fulfilled: Goals are defined for activities instead of processes, no concept of goals changing with the environment
Not fulfilled: No notion of goals evolving with the environment
Not fulfilled: No affecting environment concept
SR3
Not fulfilled: Goals are discussed on an abstract level only
Not fulfilled: “Functional objectives” on a more abstract level
Partially fulfilled: Order constraints implicitly considered via consistent process paths
Partially fulfilled: Constraints are comprised in the metamodel, but not further specified as state of activities or the environment
Not fulfilled: No notion of order constraints
Partially fulfilled: Goal aggregation might be extended to include ordering
Table 2. Available Business Objective Modeling Approaches
Since the related approaches discussed generally aim at amending process models with a descriptive goals perspective and not necessarily at using business objectives as a formal requirements definition in a BPM context, it is not
3 In the field of BPM, the terms are generally used as synonyms.
8
Matthias Lohrmann and Manfred Reichert
surprising that additional work is needed to develop a business objectives metamodel to fully address the criteria set out in Table 1.
4 Extended Business Objective Modeling Terminology
According to semantic requirement SR1 in Table 1, an effective approach to business objectives modeling must relate aspired states of target artifact properties to conditional states of additional properties of the outer environment. In the following, we will refer to the respective environmental properties as elements of the target environment (or, in short, target elements) and elements of the conditional environment (or, in short, conditional elements). Both sets of environmental elements may overlap, i.e., an environmental element may constitute a target element, a conditional element or both. We may conceive of environmental elements as “metering points” of sufficient semantic relevance to determine, in their totality, whether a business objective has been achieved. Note that the conditional elements correspond to the additional properties of the outer environment cited in semantic requirement SR1 in Table 1. The relevant “metering points” may be expressed as binary state determinants.
Definition 2 (Binary State Determinants). A binary state determinant (BSD) is the combination of an environmental element with an absolute or relative state condition that is relevant to a business objective and that may or may not be fulfilled. Conditional BSDs and target BSDs refer to conditional elements and a target elements, respectively.
On that basis, it would be possible to list all BSDs with respect to conditional elements, enumerate the possible states and relate them to the corresponding set of aspired states of the target elements, represented by target BSDs. This approach would link aspired target states to the affecting environment as demanded by semantic requirement SR1 (cf. Table 1). However, there would still be major issues regarding our effectiveness criteria, as presented in Table 3.
To address these topics, we introduce a business objectives modeling approach that (i) reflects distinct types of target BSDs, (ii) sets out with target BSDs instead of conditional BSDs, and (iii) avoids redundancies in its modeling of both the target and the conditional environment. To this end, we employ a number of terms summarized in the remainder of this section.
Definition 3 (Target BSD types). Target BSDs are constituents of the business objective. To achieve a business objective, all respective target BSDs must assume target values. Dependent on the range of target values, we discern various target BSD types.
To achieve the business objective, monovalent target BSDs must assume a “true” value (target BSDs that may only assume a “false” value are to be rephrased accordingly). There is no condition attached. Note that target BSDs subject to order constraints must include “false” in their value range.
Modeling Business Objectives for Business Process Management
9
SR2 SR3 UC1 UC2
UC3
As all target BSDs are enumerated for each conditional state, the potentially limited relevance of individual target artifacts is “hidden”.
Order constraints are not addressed, and still require an additional construct.
Semantic interrelations between elements of the outer environment, such as mutual exclusivity or correlation, are not captured.
For an individual target BSD, only a (typically small) part of the conditional environment is relevant. Hence, a relation matrix between conditional and target BSDs would only be sparsely populated. For instance, in Sample Process B (cf. Figure 2), the age of the patient is not relevant to examination B. This characteristic is not utilized which leads to a unnecessarily bloated model.
From a modeler’s perspective, it is much easier to determine (e.g. by discussion with stakeholders) what the prerequisite conditions for a target BSD are than which target BSDs are determined by a conditional element, let alone a priori enumerating relevant conditional BSDs. Moreover, semantic interrelations or relevances (cf. UC1-2) are not addressed. Capturing available knowledge is thus impeded.
Table 3. Basic Modeling vs. Effectiveness Criteria
To achieve the business objective, fully determinate bivalent target BSDs may assume either a “true” or a “false” value. We thus require only one condition attached to either “true” or “false”.
To achieve the business objective, partially determinate bivalent target BSDs may assume either a “true” or a “don’t care” value (“false” target BSDs are to be rephrased).4 “True” is bound to a respective condition.
To achieve the business objective, trivalent target BSDs may assume a “true”, a “false”, or a “don’t care” value. Trivalent target BSDs differ from bivalent ones as there are two conditions attached to “true” and “false”. The conditions are mutually exclusive, but not comprehensive (i.e. one or none of the two can evaluate to “true” at the same time).
Table 4 provides an overview on the various target BSD types and the state they must assume to enable achieving the business objective depending on the state of their relevant conditional environment.
Note that trivalent target BSDs can also be understood as two partially determinate bivalent target BSDs referring to the same target element. However, modeling a trivalent target BSD as two bivalent target BSDs results in a loss of semantics because the two respective bivalent target BSDs’ mutual exclusivity is not visible in the model.
Definition 4 (Conditional propositions). Conditions attached to target BSDs can be expressed as conditional propositions consisting of conjunctively and / or disjunctively interlinked conditional BSDs. Unlike target BSDs, the value
4 “Don’t care” implies that the business process needs to do nothing – consider, for instance, the target BSD “Purchase order value = invoice value” from Sample Process A in Figure 1, where we either need to adapt the purchase order or simply leave it as it is. Semantically, this represents the characteristic that the set of relevant target artifacts may change with the conditional environment.
10
Matthias Lohrmann and Manfred Reichert
Aspired target BSD states
Target BSD types
Condition states
Not fulfilled Fulfilled
Monovalent
n/a
X
Fully determinate bivalent
Not fulfilled Fulfilled
X X
Partially determinate Not fulfilled
bivalent
Fulfilled
X
X
X
Trivalent
Only 1st condition fulfilled Only 2nd condition fulfilled No condition fulfilled Both conditions fulfilled
X
X
X
X
May not occur
Example Examination A in Sample Process B
Invoice approval in Sample Process A
Senior management approval in Sample Process A
Marking of condition X in Sample Process B
Table 4. Target BSD Types
range of conditional BSDs is confirmed to “true” and “false”. A target element may also act as a conditional element within one business objective.
Absolute conditional BSDs compare one conditional element to an absolute value range. Relative conditional BSDs compare two conditional elements to each other.
Target BSDs are considered as conditionally equivalent if the attached conditional propositions are equivalent or if, for fully determinate bivalent target BSDs, the attached conditional propositions are a negation of each other. Target BSDs are considered as conditionally dependent on another if a BSD’s conditional proposition comprises the value another target BSD has assumed or should assume by way of a relative conditional BSD.
We identified the treatment of order constraints as a requirement towards business objective modeling (see semantic requirement SR3 in Table 1). To address this issue, we consider a number of characteristics of conditional propositions as specified in Definition 4:
– As shown in Example 6, a conditionally dependent target BSD shares conditional proposition of the “father” BSD.
– A conditional dependency exists for any two target BSDs where an order constraint applies; i.e., the dependent target BSD must be fulfilled before, after or at the same time as the “father” BSD.
– From a modeling perspective, it does not make a difference which BSD is the “dependent” one, because both are required to achieve the business objective.
We therefore introduce a convention to model conditional dependencies and order constraints as described in Table 5.
Note that conditionally dependent target BSDs to be fulfilled at the same time should be merged with their “father” BSD (i.e., the two underlying target elements should be treated as one as they must be manipulated concurrently anyway) or resolved into two (or more) sequences as appropriate.5
Example 6 (Order Constraints Modeling). Consider Sample Process B in Figure 2. The activity pairs B2 / B3 and B8 / B9 reflect that examination B has to be prepared by applying a drug while
5 Note that this issue is also not addressed in common process modeling approaches.
Matthias Lohrmann and Manfred Reichert
Ulm University, Databases and Information Systems Institute, {matthias.lohrmann,manfred.reichert}@uni-ulm.de
Abstract. For application scenarios such as the management of business process variants or business process quality, business objective models assume the role of formal requirements definitions as in software engineering. However, effective concepts in this area still constitute a gap in the presently available array of business process management methods. To address this issue, this paper develops and shortly evaluates a refined business objective modeling approach. Our approach builds on use case-based effectiveness criteria, and on insights gained from assessing the state of the art. It derives required constructs and interrelations from application scenarios, and integrates these into a business objective meta-model. As an initial validation of our concept, we model a sample scenario and match the results against effectiveness criteria.
Key words: Business Objectives, Business Goals, Business Process Modeling, Business Process Quality
1 Introduction
Definitions for the term business process range from business process reengineering approaches [1, 2] to trade associations [3] and current business process management (BPM) research [4]. They generally comprise a notion of business goals or business objectives, which can be viewed as an integral aspect reflecting the utilitarian nature of business processes. It is therefore interesting that formal modeling of business objectives is not covered by common business process modeling approaches such as BPMN [5], EPCs [6] or Workflow Nets [7].
To further illustrate the potential benefits of concise business objective modeling, we consider its possible use cases. In general, business objective models could assume the role of a formal requirements definition for business process design, implementation and enactment. Accordingly, application scenarios and benefits are generally comparable to broader requirements engineering [8, 9].
From an a priori perspective, business objective models add a layer of abstraction to business process models. They allow discussing and documenting business objectives independently from a concrete implementation, and assessing the effectiveness of implementation options. From an ex post perspective, they can be used to determine whether a business process instance (or a set
2
Matthias Lohrmann and Manfred Reichert
of instances) has terminated in a state being consistent to the organization’s business targets. In addition to these general use cases, we point out three more specific exemplary scenarios that are closely related to present directions of BPM research: automated derivation of business process models, management of business process variants, and business process quality management.
Scenario 1 (Automated Derivation of Core Business Process Models). An available business objective model would comprise formalized information on the things a respective business process should create or alter including decision criteria, ordering constraints, etc. On that basis, it would be possible to formally derive minimum control flow implementation requirements. In addition, it would be possible to integrate the approach with process mining techniques [10]. For instance, real-world cases might be used to analyze the probability of control flow decision criteria given in a business objective. This would allow for automated or even continuous control flow optimization.
Scenario 2 (Management of Business Process Variants). The management of business process variants has emerged as an important BPM issue [11]. However, determining whether two process instances are variants of the same business process remains a “missing link” in this respect, especially when considering the mining of process variants or reference processes [12], or the refactoring of model repositories [13]. Formally modeling business objectives could contribute to closing this gap, as it would enable to assess the “equivalence” of process variants with respect to a business objective.
Scenario 3 (Business Process Quality Management). Business process quality management constitutes another emerging area of BPM research. In [14], a definition framework in this regard was developed. The concept of efficacy, i.e., whether a business process achieves its business objective, is crucial in this respect. Thus, formal modeling of business objectives constitutes an important prerequisite to effectively assess business process quality in design, implementation and enactment.
Scenario 4 (Subject-oriented Business Process Management). Subject-oriented business process management (S-BPM) constitutes an approach to address critical practical issues in BPM adoption, thereby significantly broadening its appeal [15]. The concept is based on shifting the paradigm of BPM away from formalizing tasks to be executed to the roles and interactions of subjects or stakeholders. As this potentially takes out some of the implicit formality of, e.g., strict control flow, it is all the more important to employ concise business objective models to ensure effectiveness, i.e. making sure that a process still achieves what it should.
Our research has shown that present approaches to business objective modeling do not yet effectively support the application scenarios set out above. This paper therefore seeks to develop a refined solution which is methodologically well-founded as well as readily applicable in future research and for practical purposes. The remainder of the paper is structured as follows: Section 2 presents our methodology including process examples to illustrate our ideas, basic terminology, and effectiveness criteria to evaluate results. Sections 3, 4, and 5 implement our methodology, from a review of available approaches to a refined business objectives meta-model. Section 7 concludes the paper and gives an outlook on future research.
2 Methodology and Preliminary Considerations
A business objective model constitutes a goal-bound artificial construct. We therefore apply the principles of design science [16, 17]. Accordingly, our methodology consists of the following steps:
1. Define effectiveness criteria to assess the utility of design artifacts in the field of business objectives modeling (cf. Section 2.3).
Modeling Business Objectives for Business Process Management
3
2. Assess the state of the art based on the defined effectiveness criteria to determine gaps and obtain pointers towards a refined solution (cf. Section 3).
3. Build required terminology for business objectives based on effectiveness criteria and research into available approaches (cf. Section 4).
4. Build a meta-model for business objectives (cf. Section 5). 5. Evaluate our solution with respect to effectiveness criteria (cf. Section 6). 6. Discuss implications and further steps to leverage our results (cf. Section 7).
The remainder of this section presents two sample business processes we use to illustrate and evaluate our results, discusses required preliminary terms, and develops effectiveness criteria to evaluate present approaches as well as our work.
2.1 Sample Processes
Our first sample process stems from the field of accounting: invoice checking and approval constitutes a typical example of an administrative process which is often supported by workflow management systems. 1
To ensure that our concepts are also applicable to domains where workflow applications are not as common, we include a second sample process from the field of healthcare. Figures 1 and 2 show the models of the two sample processes in terms of BPMN [5] flow charts.
Example 1 (Sample Process A: Invoice Checking and Approval). The business process starts with the receipt of a supplier invoice (activity A1). The invoice is then compared to the respective purchase order (A2). If deviations exist, these are subject to approval. In practice, this is often the case when, for instance, price data have not been maintained or when no purchase order has been entered into the ERP system. If the deviation is approved (A3), the purchase order is created or adapted (A4). Otherwise, the invoice is declined (A6, A7). In the next step, the invoice is matched against goods receipt (A5) and, depending on the result, either declined (A6, A7) or passed to the next check, which is based on the invoice value. For a value of more than 5,000, senior management approval (A8) is required. If this is granted, the invoice may finally be approved (A9).
Example 2 (Sample Process B: Medical Examinations). In our alternate example from the healthcare field, a medical examination A is performed (B1). Based on its result, a drug is applied (B2) and a second examination B (B3) is performed or not. A third examination C, which may only be carried out once examination A is completed, should follow in each case (B4). Thereafter, another drug is applied depending on the result of examination C (B5) and the age of the patient. In parallel, further steps are performed depending on the results of examinations A and B: First, the existence or non-existence of condition X is noted dependent on the result of examination C (B6, B7). Then, a fourth examination D is performed (B8). After completing examination D, application of a drug is required (B9).
2.2 Basic Terminology
Business processes constitute artifacts in the sense of design science [16] which operate within an affecting and affected outer environment. The outer environment of a business process consists of target artifacts and resources, i.e. things
1 Incoming invoices processing was used to illustrate the concept of business process reengineering by both Davenport and Hammer [1, 2].
4
Matthias Lohrmann and Manfred Reichert
A1: Receive invoice
A2: Match purchase
order
Invoice Symbols
Activity
XOR Gateway (Split / Join) Start Event (Message-based)
End Event
Target Artifact
Not ok
A3: Approve deviation
A5: Match goods receipt
Invoice value > 5,000
A8: Obtain senior
approval
A4: Adapt purchase
order
Purchase order
Not approved
Not ok
Approval declined
A6: Contact supplier
A9: Approve invoice
Invoice
Invoice A7:
Decline invoice
Fig. 1. Sample Process A: Invoice checking and approval
C1: Execute examination
A
Results A
Result A > 50
C2: Apply drug I
C3: Execute examination
B
Application I
Symbols OR Gateway (Split /Join)
Results B
C4: Execute examination
C
Result C > 100 AND Age > 50
Results C
Result A > 100 OR Result B
> 100
Result C <=100
Condition X
C6: Note condition X
existent
Condition X
Result C > 100
C7: Note condition X nonexistent
C5: Apply drug II
Application II
C8: Execute examination
D
C9: Apply drug III
Results D
Application III
Fig. 2. Sample Process B: Medical examinations
the process strives to create and alter, and things required to properly do so. Note that this perspective differs in some regards from the classic BPM concepts of process input and process output as it includes things usually not considered (e.g. capital goods). This topic was discussed in more detail in [14].
In the field of BPM, business objectives represent the targets an organization aims to achieve with a business process. As illustrated in Example 3, this can be understood on a strategic, collective operational or transactional level.
Example 3 (Semantic Business Objective Levels). As another exemplary business process, consider the handling of job applications in an enterprise. On a strategic level, the business objective of this process may be understood as providing the organization with the right “human resources”. On a collective operational level, the business objective may be understood as properly handling the overall occurring cases of job applications. Depending on the required service level, the business objective may, for instance, be fulfilled if 90% of cases are managed correctly. On a transactional level, it may be understood as properly handling an individual application.
For the purpose of business objectives modeling, we define the term business objective on the transactional level to achieve consistency with common business process modeling approaches: In business process modeling, models are generally defined on a process instance [3] level without considering the cardinality of cases or instances. This means that a task that occurs many times for the business process, but one time per process instance is modeled as an individual activity, not as a set of activities.
Modeling Business Objectives for Business Process Management
5
Moreover, remember that an affecting environment may determine what actually needs to be induced to fulfil a business objective, for instance when considering decision processes (cf. Example 4).
Example 4 (The Affecting Environment of Business Objectives). Again, consider the job application process from Example 3. In this case, the business objective cannot be achieved by simply approving or disapproving an application. Rather, the respective hiring criteria are to be considered. Thus, they constitute the affecting environment of the business objective. As another example, consider medical treatments. In many cases, tests are required to find out which drugs are required. In this case, the test results are part of the affecting environment of the business objective.
Note that, when considering business objective levels as well as the affecting environment, the organizational target as the business objective on strategic level may differ from business objectives on lower semantic levels. This occurs when the affecting environnment restrains the business process from achieving the original organizational target (cf. Example 5). In other words, there may be states of the affecting environment where the business objective of the process is fulfilled while the corresponding organizational target has not been achieved.
Example 5 (Business Objective Levels and the Affecting Environment). When handling incoming job applications, the strategic organizational target will be to fill the respective positions. However, the business objective on more operational levels may well pertain to decline an applicant if her qualifications (as part of the affecting environment) are not sufficient.
In summary, this leads us to the following basic definition for business objectives to be further elaborated in our modeling approach:
Definition 1 (Business Objective). A business objective in the sense of business process management constitutes a refinement of organizational targets to the transactional level. It pertains to an affecting and affected environment. The affecting and affected environment represent the things to be considered and the things to be manipulated to achieve the business objective. The business objective relates each state of its relevant affecting environment to a set of aspired states of the affected environment.
2.3 Effectiveness Criteria
Considering the scenarios lined out in Section 1, business objective models as requirements definitions for business processes will generally be used to
– determine what needs to be done to achieve a business objective (e.g., as a starting point for structured business process design, or as in Scenario 1 from Section 1),
– assess whether a modeled business process enables to achieve its business objective (e.g., to evaluate design options, or as in Scenario 2), and
– assess whether a concrete business process instance has actually achieved its business objective (e.g., in testing, or as in Scenario 3).
Accordingly, the notion of an achieved function reflecting whether an aspired state of the affecting and affected environment of a business objective is reached is central to business objectives modeling.
Recapitulating the terms introduced in Section 2.2, business objectives are achieved by propagating target artifacts to an aspired state. However, which
6
Matthias Lohrmann and Manfred Reichert
SR1 SR2 SR3 UC1 UC2 UC3
Consideration of the affecting environment: Whether a business objective is achieved or not must be determined in terms of target artifacts and additional properties of the outer environment; e.g., in Sample Process A (cf. Example 1), the approved or disapproved invoice as a target artifact and the defined conditions for invoice approval as additional properties of the outer environment.
Varying target environment: The set of target artifacts to be created or altered as well as the concrete operations to be carried out on them may vary; e.g., in Sample Process A (cf. Example 1), the purchase order may have to be adapted or not, but the invoice must always be approved or disapproved.
Order constraints: There may be constraints regarding the order in which the activities of a process need to be executed in conformance with the business objective. Consider, for instance, Sample Process B from Example 2: drug application and examinations must occur in a specific order. It is important to note that these constraints actually represent constraints with respect to target artifacts manipulation, because, by definition, executing activities cannot constitute a business objective.
Semantic interdependencies: The approach should be apt to transparently capture semantic interdependencies between elements of the outer environment like mutual exclusivity or correlation. As an example for mutual exclusivity, consider the approval or disapproval of invoices in Sample Process A from Example 1 (cf. “pragmatic quality” in the sense of comprehension in [18]).
Model compaction: The approach should lead to a compact result in the sense of avoiding unnecessary content which might “hide” the relevance of model elements. For instance, in Sample Process A, it would be obstructive to model the effect of senior management approval for invoices below a value of 5,000 (cf. “semantic quality” in the sense of validity or relevance to the problem in [18]).
Knowledge externalisation: The approach should leverage implicitly available knowledge of the modeler (cf. “physical quality” in the sense of externalisation in [18]).
Table 1. Effectiveness Criteria for Business Objective Modeling Approaches
target artifacts need to be created or altered, and which states are considered as aspired may depend on other elements of the affecting environment.2 Thus, business objectives cannot be recorded solely in terms of attributes of targets artifacts, but in terms of a set of consistency rules to be satisfied in respect to the entire environment. This set of rules must be complete and free of overlaps to ensure conformance can be assessed for each state of the outer environment.
Table 1 summarizes effectiveness criteria towards business objectives modeling. The semantic requirements SR1 to SR3 are based on the issues discussed above. They reflect the semantic content an approach needs to address to properly model business objectives. In addition, an effective modeling approach will also fulfill usability criteria UC1 to UC3 to support both modelers and users. The usability criteria are based on the considerations on model quality in [18]. Since we work on a meta-model level instead of the model level addressed in [18], we place special regard to the quality types of “physical quality”, “semantic quality” and “pragmatic quality”.
2 Note that the affecting environment of a business objective may differ from the affecting environment of an associated business process – the affecting environment of an efficacious business process will encompass, but possibly not be limited to, the affecting environment of its business objective (cf. [14]).
Modeling Business Objectives for Business Process Management
7
3 State of the Art
Models for business objectives or goals3 have been proposed by Kueng and Kawalek [19], Neiger and Churilov [20], Soffer and Wand [21], and Lin and Sølvberg [22]. Markovic and Kowalkiewicz [23] proposed a business goal ontology as part of the SUPER project on semantic BPM (cf., e.g., [24]). For comparison, we include an approach by Engelman et al. towards goals modeling in enterprise architecture. Table 2 matches the approaches against semantic requirements SR1 to SR3. For reasons of brevity, usability criteria UC1 to UC3 are not considered.
Evaluation against semantic requirements (cf. Table 1)
Source / focus
Kueng and Kawalek [19]: Goals-based modeling, design evaluation
Neiger and Churilov [20]: “Value-focused thinking” to structure objectives
Soffer and Wand [21]: Formalizing processes’ contribution to “soft goals”
Lin and Sølvberg [22]: Goal ontology for semantic annotation in distributed environments
Markovic and Kowalkiewicz [23]: Integrating goals into business process modeling
Engelsman et al. [25]: Enterprise architecture goals modeling language
SR1
Not fulfilled: No formal measurable definition of goals
Not fulfilled: No formal measurable definition of objectives
Not fulfilled: Business goals as any possible process termination state, goal achievement only pertains to target artifacts
Partially fulfilled: Goals are seen as states of activities or artifacts, but no specification of respective artifact states
Not fulfilled: No concise definition of when a goal has been achieved
Not fulfilled: Hard goals concept, but no formal notion of goal achievement
SR2
Not fulfilled: Goals are discussed on an abstract level only
Not fulfilled: “Functional objectives” on a more abstract level
Partially fulfilled: Implicitly considered: only one relevant process path required per target artifact
Not fulfilled: Goals are defined for activities instead of processes, no concept of goals changing with the environment
Not fulfilled: No notion of goals evolving with the environment
Not fulfilled: No affecting environment concept
SR3
Not fulfilled: Goals are discussed on an abstract level only
Not fulfilled: “Functional objectives” on a more abstract level
Partially fulfilled: Order constraints implicitly considered via consistent process paths
Partially fulfilled: Constraints are comprised in the metamodel, but not further specified as state of activities or the environment
Not fulfilled: No notion of order constraints
Partially fulfilled: Goal aggregation might be extended to include ordering
Table 2. Available Business Objective Modeling Approaches
Since the related approaches discussed generally aim at amending process models with a descriptive goals perspective and not necessarily at using business objectives as a formal requirements definition in a BPM context, it is not
3 In the field of BPM, the terms are generally used as synonyms.
8
Matthias Lohrmann and Manfred Reichert
surprising that additional work is needed to develop a business objectives metamodel to fully address the criteria set out in Table 1.
4 Extended Business Objective Modeling Terminology
According to semantic requirement SR1 in Table 1, an effective approach to business objectives modeling must relate aspired states of target artifact properties to conditional states of additional properties of the outer environment. In the following, we will refer to the respective environmental properties as elements of the target environment (or, in short, target elements) and elements of the conditional environment (or, in short, conditional elements). Both sets of environmental elements may overlap, i.e., an environmental element may constitute a target element, a conditional element or both. We may conceive of environmental elements as “metering points” of sufficient semantic relevance to determine, in their totality, whether a business objective has been achieved. Note that the conditional elements correspond to the additional properties of the outer environment cited in semantic requirement SR1 in Table 1. The relevant “metering points” may be expressed as binary state determinants.
Definition 2 (Binary State Determinants). A binary state determinant (BSD) is the combination of an environmental element with an absolute or relative state condition that is relevant to a business objective and that may or may not be fulfilled. Conditional BSDs and target BSDs refer to conditional elements and a target elements, respectively.
On that basis, it would be possible to list all BSDs with respect to conditional elements, enumerate the possible states and relate them to the corresponding set of aspired states of the target elements, represented by target BSDs. This approach would link aspired target states to the affecting environment as demanded by semantic requirement SR1 (cf. Table 1). However, there would still be major issues regarding our effectiveness criteria, as presented in Table 3.
To address these topics, we introduce a business objectives modeling approach that (i) reflects distinct types of target BSDs, (ii) sets out with target BSDs instead of conditional BSDs, and (iii) avoids redundancies in its modeling of both the target and the conditional environment. To this end, we employ a number of terms summarized in the remainder of this section.
Definition 3 (Target BSD types). Target BSDs are constituents of the business objective. To achieve a business objective, all respective target BSDs must assume target values. Dependent on the range of target values, we discern various target BSD types.
To achieve the business objective, monovalent target BSDs must assume a “true” value (target BSDs that may only assume a “false” value are to be rephrased accordingly). There is no condition attached. Note that target BSDs subject to order constraints must include “false” in their value range.
Modeling Business Objectives for Business Process Management
9
SR2 SR3 UC1 UC2
UC3
As all target BSDs are enumerated for each conditional state, the potentially limited relevance of individual target artifacts is “hidden”.
Order constraints are not addressed, and still require an additional construct.
Semantic interrelations between elements of the outer environment, such as mutual exclusivity or correlation, are not captured.
For an individual target BSD, only a (typically small) part of the conditional environment is relevant. Hence, a relation matrix between conditional and target BSDs would only be sparsely populated. For instance, in Sample Process B (cf. Figure 2), the age of the patient is not relevant to examination B. This characteristic is not utilized which leads to a unnecessarily bloated model.
From a modeler’s perspective, it is much easier to determine (e.g. by discussion with stakeholders) what the prerequisite conditions for a target BSD are than which target BSDs are determined by a conditional element, let alone a priori enumerating relevant conditional BSDs. Moreover, semantic interrelations or relevances (cf. UC1-2) are not addressed. Capturing available knowledge is thus impeded.
Table 3. Basic Modeling vs. Effectiveness Criteria
To achieve the business objective, fully determinate bivalent target BSDs may assume either a “true” or a “false” value. We thus require only one condition attached to either “true” or “false”.
To achieve the business objective, partially determinate bivalent target BSDs may assume either a “true” or a “don’t care” value (“false” target BSDs are to be rephrased).4 “True” is bound to a respective condition.
To achieve the business objective, trivalent target BSDs may assume a “true”, a “false”, or a “don’t care” value. Trivalent target BSDs differ from bivalent ones as there are two conditions attached to “true” and “false”. The conditions are mutually exclusive, but not comprehensive (i.e. one or none of the two can evaluate to “true” at the same time).
Table 4 provides an overview on the various target BSD types and the state they must assume to enable achieving the business objective depending on the state of their relevant conditional environment.
Note that trivalent target BSDs can also be understood as two partially determinate bivalent target BSDs referring to the same target element. However, modeling a trivalent target BSD as two bivalent target BSDs results in a loss of semantics because the two respective bivalent target BSDs’ mutual exclusivity is not visible in the model.
Definition 4 (Conditional propositions). Conditions attached to target BSDs can be expressed as conditional propositions consisting of conjunctively and / or disjunctively interlinked conditional BSDs. Unlike target BSDs, the value
4 “Don’t care” implies that the business process needs to do nothing – consider, for instance, the target BSD “Purchase order value = invoice value” from Sample Process A in Figure 1, where we either need to adapt the purchase order or simply leave it as it is. Semantically, this represents the characteristic that the set of relevant target artifacts may change with the conditional environment.
10
Matthias Lohrmann and Manfred Reichert
Aspired target BSD states
Target BSD types
Condition states
Not fulfilled Fulfilled
Monovalent
n/a
X
Fully determinate bivalent
Not fulfilled Fulfilled
X X
Partially determinate Not fulfilled
bivalent
Fulfilled
X
X
X
Trivalent
Only 1st condition fulfilled Only 2nd condition fulfilled No condition fulfilled Both conditions fulfilled
X
X
X
X
May not occur
Example Examination A in Sample Process B
Invoice approval in Sample Process A
Senior management approval in Sample Process A
Marking of condition X in Sample Process B
Table 4. Target BSD Types
range of conditional BSDs is confirmed to “true” and “false”. A target element may also act as a conditional element within one business objective.
Absolute conditional BSDs compare one conditional element to an absolute value range. Relative conditional BSDs compare two conditional elements to each other.
Target BSDs are considered as conditionally equivalent if the attached conditional propositions are equivalent or if, for fully determinate bivalent target BSDs, the attached conditional propositions are a negation of each other. Target BSDs are considered as conditionally dependent on another if a BSD’s conditional proposition comprises the value another target BSD has assumed or should assume by way of a relative conditional BSD.
We identified the treatment of order constraints as a requirement towards business objective modeling (see semantic requirement SR3 in Table 1). To address this issue, we consider a number of characteristics of conditional propositions as specified in Definition 4:
– As shown in Example 6, a conditionally dependent target BSD shares conditional proposition of the “father” BSD.
– A conditional dependency exists for any two target BSDs where an order constraint applies; i.e., the dependent target BSD must be fulfilled before, after or at the same time as the “father” BSD.
– From a modeling perspective, it does not make a difference which BSD is the “dependent” one, because both are required to achieve the business objective.
We therefore introduce a convention to model conditional dependencies and order constraints as described in Table 5.
Note that conditionally dependent target BSDs to be fulfilled at the same time should be merged with their “father” BSD (i.e., the two underlying target elements should be treated as one as they must be manipulated concurrently anyway) or resolved into two (or more) sequences as appropriate.5
Example 6 (Order Constraints Modeling). Consider Sample Process B in Figure 2. The activity pairs B2 / B3 and B8 / B9 reflect that examination B has to be prepared by applying a drug while
5 Note that this issue is also not addressed in common process modeling approaches.