LOG 101/LOG104 Module 4

Business Process Management (BPM) and

Business Decision Management (BDM)

Definition of a Business Process

A business process is defined as a series of repeatable, defined activities taking place
in a planned sequence by actors (being individuals or systems) within a defined scope
of organization where the tasks add value to a good or a service for a customer.
Business processes are important, some more than others. A business designs,
implements, manages, monitors, and optimizes them to obtain advantage. The goal in
managing business processes is to provide customers with outstanding products or
services, or to lower costs. In short, improvement in business processes aims to
perfect business performance.
A business process is wide in scope, an end-to-end chain, rather than a functional
narrow view. So, a business process is less concerned with the functional
departmentalization of the organization, than with the breadth of business processes
that deliver value to the customer. So, a business process exists regardless of, and
spanning, the functions of the organization. In this way, the focus is on the value
chain of the organization. The value chain is simply the set of steps by which the
business adds value to the goods or services delivered to customers.
Example of a Business Process
Within an airline, one business process is the customer’s interaction from the moment
the customer inquiries about a flight to that customer’s completion of the journey,
referred to as the “Customer Trip Process.” It involves many steps, including inquiring
about flight times and cost, completing the reservation process, arriving, and waiting
at the airport, boarding the plane, and so on until the end of the trip. Of course, this
business process involves many different departments and personnel from the airline.
It may also include the hiring of a car from one of the airline’s rental car partners
because wide business processes may cross the boundaries of the organization to
include partner and customer organizations.
In addition to spanning multiple departments or functions of an organization,
business processes also span a significant period. The whole “Customer Trip Process”
can take days, weeks, or months from start to finish. Hence, business processes are
“long-running transactions.”
To improve business processes, a business designs, implements, possibly automates,
and continually improves them. A whole theory of process improvement has
evolved, using techniques for creating an abstract visual representation called a
business process model. This assists in gaining a shared understanding of the
business process among stakeholders. Today, automated modeling tools for producing
business process models can simulate the business process and serve as a source of
building blocks when automating it. There are many different diagrams that represent
parts of business process models, including flowcharts and activity diagrams, swim
lanes and process charts, and process and functional decomposition diagrams.
Regardless of which types of diagrams are preferred, most business process models
today do not separate business decisions from the business process. Instead, the
business logic of the business decisions is merged into the visual representation of the
business process flow. This leads to the creation of inefficient processes that are
difficult to modify. Such business processes do not enable optimum business agility
even when agility is the main objective. That is because such business processes are
not decision aware.

Definition of a Decision-Aware Business Process

A decision-aware business process as one that is designed to distinguish between
tasks that perform work (i.e., process tasks) and tasks that come to conclusions based
on business logic (i.e., decision tasks). Because a decision-aware business process
makes this distinction, the details behind a decision task are separated from the
details behind the process task. This separation enables the details behind a decision
task (i.e., business logic) to be represented in a different kind of model, specific to
business logic.
To manage and improve business decisions, they need to be separated from the
business processes that rely on them. To separate business processes and business
decisions, they must somehow be different from each other in a recognizable way. It
turns out that they are uniquely different in a significant way. In fact, the inherent
nature of a business process is quite different from that of a business decision. To
date, however, this difference has not been well understood, but the advent of the
Decision Model brings this difference to the forefront.
Essentially, a business process is procedural in nature, but a business decision is
declarative in nature. However, without a clear understanding of declarative versus
procedural nature, common practice involves creating business process models in
which business decisions are loosely represented as just another part of the business
process. In other words, it is common practice to model business processes and
business decisions in a procedural manner rather than modeling the latter in a
declarative manner. This common practice not only constrains the business decision
unnecessarily, but it also seriously hinders agility for both the business process and
the business decision. Understanding the difference between a business process and a
business decision means distinguishing and preserving the difference between a
procedural versus declarative solution.
Distinguishing a Procedural Task from a Declarative Decision
A procedural solution specifies how, in a step-by-step manner, something is to be
done. So, a business process model is a procedural solution because it prescribes a
set of tasks that are carried out in a particular sequence. The business process model
is the “How” of a unit of work.
A declarative solution, on the other hand, only specifies what needs to be done, with
no details as to how, in a step-by-step manner, it is to be carried out, because
sequence is irrelevant to arriving at the correct result. A Decision Model is a
declarative solution because it is a set of unordered business logic, not a set of ordered
tasks. A Decision Model is the “What” of a special kind of unit of work. “HOW means
saying how, step by step, the work is to be done; WHAT just means saying what the
work to be done is” (Date, 2000).
The declarative Decision Model for a business decision should be removed from the
procedural business process so that it can be managed separately in a declarative
form.
Figure 4.1 summarizes the visual distinction between a procedural business process
model and a declarative Decision Model.
Example #1: Separation of Business Decisions from Business Process
Consider a small piece of a business process model to determine a person’s credit
rating.
Option 1 in the business process models in Figure 4.2 prescribes that first the process
determines a person’s employment history, and then if the result is good, the process
next determines the person’s debt. If the debt is low, the process sets the person’s
credit rating to “A.” However, if the results are bad and high, respectively, the process
branches elsewhere. In this business process flow, the sequence of evaluating the
business criteria or conditions is set in a specific order. The process flow is rigidly
specified, not allowing for alternative sequencing.
Yet Option 2 prescribes a different sequence that also works, although this process
flow likewise does not allow for alternative sequencing.
Option 3 offers a significant improvement simply by removing the declarative business
decision from the procedural process flow. It represents a simpler process flow
consisting of only one task. That task combines the whole previously sequential set of
tasks into one task, denoted as a decision task, behind which a business decision
executes in a declarative fashion. Within the process flow, the decision task looks like
any other task but contains a decision shape within the task box. Option 3 also
includes the Decision Model diagram, which puts the Decision Rule Family in context
with its related Rule Families, and Option 3 includes a Rule Family table for the
Decision Rule Family. Neither the Rule Family table nor the Decision Model diagram is
embedded in the process flow. They are separate deliverables, anchored to the process
flow by the decision shape.
Immediate observations are that Option 3 is an improvement over Options 1 and 2
because it
◾ Allows a much simpler business process model
◾ Easily highlights all possible combinations of conditions
◾ Permits changes in the Decision Model without changing the business process
model
◾ Permits changes in the business process model without changing the Decision
Model
Example #2: A Business Process Model Never Reveals All Business Logic
The previous example illustrated that business process models that do not separate
business decisions from process tasks bury some business logic in the business
process model itself. Example #2 now illustrates that, even when this is so, it is
usually impossible to resurrect all business logic from such a business process model.
*SOA – Service-oriented architecture

Figure 4.3 shows two business process models for determining Food Stamp (FS)
eligibility. Option 2 depicts a much simpler business process model than does Option
1. That is because Option 1 depicts a sequence of process tasks that are forced to
occur in a particular sequence but for which such sequence is not required. The
business process model is simplified by removing parts of it that can be represented in
a declarative Decision Model. So, the high-level Decision Model in Figure 4.4
represents the business decision “Determine FS Eligibility.”
Although the Decision Model contains business logic from several of the tasks in
Option 1, namely, FS Eligibility and Children Qualification, it also contains several
Rule Families that are not represented by process tasks in the business process
model: Citizenship Status, SSN Validation, Employment Status, and Income
Qualification. So, mingling business decision logic with process flow as in Option 1
does not necessarily expose all the business logic in that process flow.
Example #3: Simplicity, Productivity, and Cost Savings
The business process model in Figure 4.5 is based on a real project and is a typical
representation of a business process model when it is depicted without regard for
whole business decisions. Some of the tasks evaluate one condition, so the sequence
of such tasks imposes a sequence on the evaluation of those conditions. Further, the
model contains textual annotations in red representing other business logic (or
business rules) that are not represented as tasks in the model itself.
So, the business logic has two different kinds of representations, neither of which
seems optimal. It is not difficult to imagine that producing such business process
models is time consuming, and they quickly become complex. Management of the
business logic and business rules becomes tedious, if not impossible, because some of
it is stated explicitly, some is buried in the business process model itself, and some is
probably missing. In fact, this business process model became so unmanageable that
the client gave up maintaining it, the typical result for models that mix process and
logic, because they are not decision aware.
However, the business process model in Figure 4.6 is a reengineering of the one in
Figure 4.5, but with one subtle and important difference: The business decisions are
noted simply by the decision icon within decision tasks. (The notation style difference
between the two diagrams may be ignored.) The corresponding business logic
statements or business rules are nowhere on this diagram. This solution depicts tasks
in a prescribed sequence, differentiating those tasks representing a conclusion carried
out through business logic. The detailed business logic is captured in corresponding
Decision Models.

Simplification became obvious when the quantity of business process models for the
entire project was reduced from approximately 25 to 10. Additionally, at least 5 of
those business process models were reused elsewhere because removing business
logic resulted in more generic business process models. Most of the Decision Models
also became candidates for reuse.
The diagram in Figure 4.7 illustrates one of the project’s business process models and
how its Decision Models represent all the business logic alluded to in the original
deliverable but more completely, accurately, and visually. The business process model,
devoid of business logic in Figure 4.6, contains visible anchor points (e.g., decision
shapes within task boxes) for five Decision Models. One of those Decision Models is
shown in Figure 4.7, complete with its Decision Rule Family and five other Rule
Families. Three of those Rule Families appear as Rule Family tables.