Modeling Business Decisions and Processes
Which Comes First?
Jan Vanthienen and Filip Caron
Department of Decision Sciences and Information Management, Faculty of Economics and Business, KU Leuven,
Naamsestraat 69, 3000 Leuven, Belgium
Keywords: Decision Structuring, Decision Dependencies, Decision Modeling, Business Processes.
Abstract: Decisions are often not adequately modeled. They are hardcoded in process models or other representations,
but not modeled in a systematic way. Because of this hardcoding or inclusion in other models, organizations
often lack the necessary flexibility, maintainability and traceability in their business operations.
We propose to first model the structure of the decision. Next, starting from this declarative model, a set of
processes are built or derived, which are ultimately evaluated against a set of business criteria. This
approach aims to develop a roadmap for the modeling of business processes based on decisions structures,
and examines the challenges that arise when such decision structures are eventually transformed into more
optimal execution-system geared business processes.
1 INTRODUCTION
Most processes and business process models include
decisions of some kind. For example, in Business
Process Modeling and Notation (BPMN) (OMG,
2006), decisions are made in flow forks or are
represented by a diamond. Decisions are typically
based on a number of business (decision) rules that
describe the premises and outcomes of specific
situations. Sometimes, if the decision is more
complex, the entire decision can be included as a
decision activity or as a service (a decision service).
Typical decisions are: creditworthiness of the
customer in a financial process, claim acceptance in
an insurance process, eligibility decision in social
security, etc. The process then handles a number of
steps, shows the appropriate decision points and
represents the path to follow for each of the
alternatives.
In the business modeling community, it has been
observed for some time that although a standard
notation for business processes exists (BPMN), there
is no standard notation for decisions up till now.
That will be the mission of the OMG Decision
Modeling and Notation proposal. It is indeed strange
to observe how business process models are
describing (and automating) the process including
major decisions, without modeling the decision
logic or structure itself. Decisions are based on
decision criteria, require one or more subdecisions
(Vanthienen, 1995), use a simple or complex
decision technique (Vanthienen, 1996) and conclude
one or more decision results.
Moreover, in a large number of cases, the
process does not just contain decisions, but the entire
process is about making a decision. The major
purpose of a loan process e.g., or an insurance claim
process, etc., is to prepare and make a final decision.
The process shows different steps, models the
communication between parties, records the decision
and returns the result. The decision process,
however, is not the same thing as the decision
structure (Codasyl, 1982), because a specific process
is only one possible way to implement the decision.
There may be many possible process models, so it
is worth examining the relationship between
decisions and processes.
In this paper, we state that the design of the
process (according to the relevant criteria) is not
independent from the structure of the decision. And
therefore it is worthwhile to model the decision first,
and only then design, choose, or even derive the
business process model.
This paper is structured as follows. Section 2
gives a summary of the relevant literature. In section
3 we discuss the decision structures for modeling
decisions. Section 4 reports on the translation into
decision process models that can be evaluated and
451
Vanthienen J. and Caron F..
Modeling Business Decisions and Processes - Which Comes First?.
DOI: 10.5220/0004623904510456
In Proceedings of the International Conference on Knowledge Discovery and Information Retrieval and the International Conference on Knowledge
Management and Information Sharing (KMIS-2013), pages 451-456
ISBN: 978-989-8565-75-4
Copyright
c
2013 SCITEPRESS (Science and Technology Publications, Lda.)
compared to each other. Section 5 concludes the
paper.
2 RELATED WORK
Browne et al. (2004) define a structure in which high
level goals are decomposed into goal graphs that are
finally used to design a process model. However
Browne only derives one execution path where we
would like to derive many and compare them to each
other. Lars Braubach et al. (2010) present a goal-
oriented process modeling approach, which extends
concepts from goal-driven process design (Jacobs,
1995). Yet, concerning the decision making
processes, especially those decisions that span across
several business processes, the goals elicited for
individual process are not necessarily aligned
together to represent the characteristics of the final
decision.
A related approach, namely Product Based
Workflow Design (PBWD) is presented in
(Vanderfeesten, 2007). Similarities can be found
between PBWD and case handling workflow
management systems, as they focus on the data
elements rather than on the control flow of the
process. Our approach is related, but focuses more
on the decisions than on the data, and builds upon
our earlier research in this area (De Roover, 2011).
An interesting approach can be found in declarative
process modeling which focuses on modeling the
minimal business concerns, and leaves as much
freedom as permissible to determine a valid and
suitable execution plan. Examples of such approach
can be found in (Braubach, 2010). Declarative
process modeling however puts more focus on
describing the process constraints.
Modeling decisions in processes is also the
subject of DMN (the OMG Decision Modeling and
Notation proposal, under construction).
3 MODELING DECISIONS AND
DECISION STRUCTURES
Modeling processes without explicitly considering
the structure of the decision has some severe
drawbacks, because the real decision is then hidden
in the process. Process models often contain
decision tree-like flows that are hardcoded. This can
lead to a lack of traceability if the decision structure
changes (finding out what the impact of the change
is, determining who is responsible, etc.).
Additionally, these processes can be hard to
maintain, because the decision structure is not
available. Especially if the process is (re)designed
without explicitly modeling the decision, the process
may be implementing an undesirable decision
procedure which is the result of historical process
steps, responsibilities, roles or structures (‘the
procedure is like this because the decision has
always been taken that way’).
3.1 Separating Rules and Processes
Taking the decision rules and decision details out of
process models is already common practice. When
decision rules for a process task are isolated (e.g. in
a BPMN rule task), the process is simplified and
more flexible, because it is reduced to its essence.
There is more however. For a given decision
(structure), the decision process could be organized
in different ways, according to various criteria
(Reijers, 2005):
- The process can try to optimize the company’s
resources, given a minimum service level
- The process can focus on minimal average
waiting time, from the customer’s point of
view
- The process can try to minimize customer
contacts (touch points), by having all
information available upfront
- The process can try to minimize redundant
information requests, only asking the customer
information when and where it is needed
- The process can focus on other criteria, such as
collaboration, organizational structures, etc.
3.2 Modeling Decisions without
Hardcoding Execution
Modeling decisions is not (at first) about process
steps, but about the (declarative) structure of the
decision. It is examined how the logic of a decision
can be represented, independent of its
implementation. What are elements of a decision?
What types of subdecisions exist? What are possible
relations between decision elements? This research
question builds on earlier research about decision
structures and normalization and factoring
(Vanthienen & Wets, 1995; Vanthienen & Wijsen,
1996; Vanthienen & Snoeck, 1993).
This is the common concept of a decision-goal
tree, a partitioning of a decision into subdecisions.
It captures the business logic that is needed to make
a decision by subdividing the decision. Hence a
KMIS2013-InternationalConferenceonKnowledgeManagementandInformationSharing
452
model is created that governs the essence of a
decision namely the structure and the internal logic
of the decision. The concept of a decision goal tree
is similar to a general goal tree (Letier & Van
Lamsweerde, 2002; Kavakli and Loucopoulos,
2006), but each decision and lower level decision
can have a number of extra attributes: data
requirements, data sources, processing time,
required lower level decisions in different
constellations (all are required, one is required, etc.).
A (preliminary) possible representation for a
decision structure is given in the figure below, where
the student visa example is modeled in terms of
criteria, subdecisions, conjunctions and disjunctions,
etc.
3.3 A Running Example: Obtaining
Citizenship
Naturalization is the acquisition of citizenship by
somebody who was not a citizen of that country
when born. Not everyone can request naturalization
and the decision whether someone can apply for a
new nationality is restricted by several requirements.
The requirements for the Belgian citizenship are
formulated by the following decisions:
• Is the applicant of legal age?
• Does the applicant has a legal residence?
(What does it mean to have a legal
residence?)
• Has Belgium been the applicant’s main
country of residence?
• Can the applicant show that he is socially
and culturally integrated?
Data inputs for each (sub) decision can be collected
from applicants or systems. Some of the data are
always
required (e.g. nationality), some are not,
depending on the situation.
The decision structure (Figure 1) reflects the
relationship between lower and upper decisions and
stays unchanged unless the most fundamental
business rules change. Therefore the model is not
subject to minor policy changes and is stable enough
to serve as a foundation for the process.
4 FROM DECISION TO PROCESS
The decision structure can be used as a guide to
develop various execution paths for the decision
process. These execution paths could be generated
by applying different strategies to the decisions and
subdecisions in the decision-goal tree.
4.1 Process Model Generation
Strategies
Strategies constrain the order in which the
subdecisions are performed, add timing constraints,
allocate decision to specific workers, etc. We list
some possible strategies, based on the search
strategies that can be used in knowledge-based
systems, and which will have to be adapted to this
problem setting:
- The sequencing strategy of the subdecisions.
The process might attempt to make the decision
according to a goal-driven or a data-driven
strategy (not unlike reasoning strategies in
Figure 1: Decision structure.
ModelingBusinessDecisionsandProcesses-WhichComesFirst?
453
knowledge-based systems). Data-driven means
that once all data for a specific subdecision are
available, the subdecision can be executed (even
if this later turns out to be an unnecessary path
because the goal decision was obtained in other
ways). Goal-driven, on the other hand, means
that different paths leading to the goal are
explored, and subdecisions and data are only
examined or requested whenever necessary.
- Parallelism of subdecisions. Whenever
decisions are executed in parallel, there may be
time gains, but if some of the decisions turn out
to be redundant, a lot of useless work has been
performed.
- Differences in complexity of (sub)decisions
based on type and outcome. Acceptance
decisions (accept/reject) often include large
differences in decision complexity or data
requirements. Some requirements may be easy,
others very hard. If the decision examines
acceptance criteria, it might be a good strategy
to first evaluate criteria that can be easily
rejected because they are not labor-intensive or
are easy to answer.
The process to reach a decision can be organized in
different ways. If a decision requires all
subrequirements to be true (AND), the
corresponding activities can be executed in a certain
order or in parallel, but any negative result will lead
to a negative total outcome. If only one
subrequirement is necessary (OR), any positive
result will trigger a positive total outcome. This
information can be used to structure the process.
Depending on the structure of the decision,
various transformation patterns can be applied to
structure the process, e.g.:
Parallel Pattern. When the criterion is to achieve
minimal throughput time, the parallel pattern is best
suited to build the process.
Sequential Pattern. When the criterion is to
minimize execution cost, the sequential pattern is
best suited to build the process.
Using one strategy or a combination of strategies
for a specific decision structure model could result
in a collection of different process models, as
rudimentarily expressed in the following figure
(Figure 2):
With the development of this approach we aim at
a process model generation method based on the
decision structure, such that the requirements of
traceability, maintainability and understandability
are now kept intact.
Evaluating Process Models
As various process models can result from one
decision goal tree, the choice between different
process models becomes an important issue. There is
a need for criteria to rate the process models such
that models can be compared to each other and the
process model that best matches the business
strategy can be chosen.
Some possible process modeling criteria are
indicated in (Reijers, 2005). It will be necessary to
examine for each specific perspective how the
criteria are related to the decision strategy and how
any shortcomings can be avoided:
Customer Perspective. This criterion
improves the relations and contacts with the
customer such that the contacts happen in
an efficient way and customer friendly
manner (e.g. single point of contact).
Business Process Behavioral Perspective.
This criterion implements the workflow in
an efficient way. An example: eliminating
redundant activities.
Business Process Optimization. This
criterion optimizes the time aspect of the
execution.
Organizational Perspective. This criterion
optimizes the organizational structure and
the involved resources.
External Environmental Perspective.
This criterion improves the collaboration
and communication with third parties.
Informational Perspective. This criterion
uses best practices for the usage of
information in business processes (e.g.
minimal data lookup strategies).
Not only should the derived business process
structure correctly implement the decision structure
and optimize a set of important business criteria, it
should also be compliant to a set of process
controls. A possible approach is to take the controls
into account during the translation of the decision
structures into process structures. This approach is
based on the genetic mining algorithm (Alves de
Medeiros, 2007) and would use multi-objective
evolutionary optimization algorithms to search for
process structures which implement the decision
structure correctly, do not violate the process
controls and optimize the business criteria.
KMIS2013-InternationalConferenceonKnowledgeManagementandInformationSharing
454
Figure 2: Possible process models.
5 DISCUSSION AND
CONCLUSIONS
The proposed method results in a better separation
between business decisions and execution processes,
which makes it easier and clearer to achieve the
above objectives. Business decisions that have been
properly modeled can be better evaluated and
improved throughout their lifecycle. Moreover, the
transformation strategy allows for added operational
agility when the characteristics (e.g. time and cost)
for obtaining lower level elements change. Future
research must focus on transformation patterns that
ModelingBusinessDecisionsandProcesses-WhichComesFirst?
455
take into account different characteristics (e.g. the
organizational aspect where the goal would be to
limit the number of handovers) or a combination of
characteristics. The approach will increase the
flexibility, traceability and maintainability of the
underlying decision making processes, while at the
same time, it minimizes the impact from changes
caused by modification of specific decision logic.
REFERENCES
Alves de Medeiros, A., Weijters, A., and van der Aalst,
W.M.P., 2007. Genetic process mining: an
experimental evaluation. Data Mining and Knowedge
Discovery, 14(2), pp. 245-304.
Braubach, L., 2010. Go4flex: Goal-oriented process
modelling. Intelligent Distributed Computing IV, 315:
p. 77.
Browne E.D., Schrefl M., and Warren J.R., 2003. A Two
Tier, Goal-Driven Workflow Model for the Healthcare
Domain. In Proceedings of the 5th International
Conference on Enterprise Information Systems,
volume III - Information Systems Analysis and
Specification, pages 32–39.
Codasyl, 1982. Modern appraisal of decision tables.
Report of the Decision Table Task Group, pages 230-
232.
De Roover W. and Vanthienen J., 2011. On the relation
between decision structures, tables and processes On
the Move 2011 - Semantic & Decision Support
(Crete).
Jacobs, S. and Holten, R., 1995. Goal driven business
modelling: supporting decision making within
information systems development, in Proceedings of
conference on Organizational computing systems,
ACM: Milpitas, California, United States. p. 96-105.
Kavakli, V., and Loucopoulos, P., 1999. "Goal-Driven
Business Process Analysis - Application in Electricity
Deregulation." Information Systems 24(3): 187-207.
Letier E., and van Lamsweerde A., 2002. Deriving
Operational Software Specifications from System
Goals. Proc. FSE’10: 10th ACM Symp. On the
Foundations of Software Engineering, Charleston.
Object Management Group, 2006. Business Process
Modeling Notation (BPMN) –final adopted
specification. OMG Document - dtc/06-02-01.
Reijers H.A., and Limam Mansar S., 2005. Best practices
in business process redesign: an overview and
qualitative evaluation of successful redesign
heuristics. Omega, 33(4), pp.283-306.
van der Aalst, W.M.P., 1999. On the automatic generation
of workflow processes based on product structures.
Computers in Industry. 39(2): p. 97-111.
Vanderfeesten, I., H.A. Reijers, and W.M.P.v.d. Aalst, an
evaluation of case handling systems for product based
workflow design. ICEIS 2007 - International
Conference on Enterprise Information Systems, 2007.
Vanthienen J., and Snoeck M., 1993. Knowledge
Factoring Using Normalization Theory, International
Symposium on the Management of Industrial and
Corporate Knowledge (ISMICK'93), Compiègne (FR),
pp. 97-106.
Vanthienen J. and Wijsen J., 1996. On the Decomposition
of Tabular Knowledge Systems, New Review of
Applied Expert Systems, pp. 77-89.
Vanthienen, J., and Wets, G., 1995. Integration of the
decision table formalism with a relational database
environment, Information Systems. 20(7): pp. 595 -
616.
Vanthienen, J., and Wijsen, J., 1996. On the
decomposition of tabular knowledge systems. DTEW
Research Report 9604, pages 1-12.
KMIS2013-InternationalConferenceonKnowledgeManagementandInformationSharing
456
