CHAPTER 4:
BPM AND 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
Note that 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 (functional silos) 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.
For example, within an airline, one business process is the customer’s
interaction from the moment the customer inquires 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.
service for a customer.
In addition to spanning multiple departments or functional silos of an
organization, business processes also span a significant period of time. The
whole “Customer Trip Process” can take days, To improve business
weeks, or months from start to finish. Hence, processes, a business
business processes are “long-running designs, implements,
transactions.” possibly automates, and
continually improves
There are many different diagrams that represent parts of
them. A whole theory of
business process models, including flowcharts and activity process improvement
diagrams, swim lanes and process charts, and process and has evolved, using
functional decomposition diagrams. techniques for creating
an abstract visual
representation called a
Definition of a Decision-Aware Business Process business process
model.
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. However, most business processes
today are not designed to be decision aware.
“Although organizations have automated standard processes with enterprise
software, these operational decisions haven’t been the focus of investment. They
are overwhelmingly made manually or automated poorly, which is a mistake.
Embedding business processes in systems to streamline operations but not
managing and improving these decisions leaves half the opportunities for
improvement untouched” - (Taylor and Raden, 2007).
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 truly different in a very significant way. In fact, the inherent
nature of a business process is very different from that of a business decision.
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 modelling the latter in a
declarative manner. This common practice not only constrains the business decision
unnecessarily, it seriously hinders agility for both the business process and the
business decision.
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.
Separating business decisions from business process tasks simplifies the business
process model, offers more creativity in organizing the business logic, and delivers
the business logic in a form that transcends technology options. These advantages
become clear in the following examples.
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.

The differences between a business process and business decision is summarized
in Table 4.
Table 4.2 summarizes the disadvantages of not separating business decisions
from business processes.
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.
(Note: I will not discuss the Figure 4.3 to 4.7, in case that you noticed it is missing.)
In a Decision Model, the business logic in one business decision is a chain of
inferential dependencies. The inferential nature of business logic within a
business decision makes it amenable to having its own model, with distinct
boundaries and distinct connections to business processes as needed. In this
way, the Decision Model can be viewed, managed, and executed as one whole set
of business logic, as a black box evaluating conditions and reaching a conclusion.
Example #3: Simplicity, Productivity, and Cost Savings
(Let’s skip unessential parts.)

Example #4: When Business Logic Requires Deliberate Sequence
There are, however, certain circumstances when sequence of business logic
execution is relevant to arriving at the correct conclusion. In such
circumstances, a single Decision Model does not suffice. The business logic must
be divided into multiple Decision Models, each linked to a separate process task.
In this way, the deliberate sequence of the process tasks enforces the sequence
of Decision Model execution because business process models enforce sequence
and Decision Models do not.
However, there are business circumstances that require separate business
decisions and Decision Models. First, each business decision may be governed by
a different group, hence having separate Decision Models facilitates separate
governing bodies for the business logic. Second, there may be a process task that
needs to take place after one conclusion based on the first conclusion before
arriving at the other conclusion (i.e., sequence!) such as sending a message
based on the first conclusion. These are some of the circumstances that dictate a
required sequence (even if the pure business logic itself does not require a
sequence).
So, the business process model is simplified and collapsed by removing business
decisions from the business process model when sequence is not required
within the business decision logic. Business decisions are therefore represented,
not by spreading or diluting them across process tasks and imposing
unnecessary sequence, but by separating them in declarative Decision Models
that sit behind a decision task. In this way, the business decision is represented
as a separate model from that of the business process model, can be managed
independently, and can share its conclusions with business processes. This also
implies that a business process model is not the optimum way to visualize the
business logic of a business decision.
The previous examples dealt with operational business decisions (i.e., guiding
operational business transactions). The next example illustrates that separating
business decisions from business process is also powerful when dealing with
strategic business processes and corresponding business decisions.
Example #5: Separation of Business Decision for Non-operational Business
Decisions
In 2000, Pitney Bowes, a $7 billion U.S. corporation, made a strategic business
decision to transform itself from a hardware-oriented provider of mail-room
equipment to a software and service-oriented provider. The tactical approach
for achieving this was to do so through acquisitions.
So, Pitney Bowes purposely formalized its acquisition business process, identifying places
where important business decisions were needed, and creating rigor around
corresponding fact-based business decisions. Over time the acquisition business process
and corresponding business decisions have been improved based on experience, but the
essentials have remained constant. (Nolop, 2007)
The Pitney Bowes case not only better defined a strategic business process, but also
developed fact-based business decisions that likely are worth tens or hundreds of
millions, or even billions, of dollars and which are only executed a few times a year. By
elevating the acquisition business process to a formally defined business process, and
managing the business decisions separately from the business process, Pitney Bowes
were able to place these strategic business decisions into the simple operative context.
Eight years later, the company had made 83 acquisitions, a rate of over 10 per year, while
investing $2.5 billion. The acquisitions have caused revenue to grow by 25%, substantially
accelerated organic growth, and made a positive contribution to net income and cash
flow.
This example confirms what Chapter 3 pointed out—that the management
of business decisions and Decision Models is valuable for decisions made at various
management levels: strategic, tactical, and operational. Of importance is the
Complex operative context and how much that may be reduced to a Simple context.
If all the facts can be known, the business decision functions in the orderly operative
context and can be modelled fully in a Decision Model.
Example #6: When Business Process Excellence Alone Is Insufficient for Competitive
Advantage
An excellent example of business process excellence alone being insufficient for
competitive advantage is Dell. Long the dominant PC Company, Dell had achieved
leadership through the creation of an outstanding supply chain, coupled with a razor-
sharp focus on their peerless direct sales channel. With every possible cent squeezed out
of their cost, and the ability to deliver attractive product at the lowest conceivable cost
directly to the consumer, they dominated the PC world for many years. However, in the
space of four short years Dell slipped to second, perhaps third, place in computer sales
and their stock price has halved, as shown in Figure 4.8. What happened?

It appears that Dell’s operational excellence, delivered through its hyper-efficient
business processes, failed to provide the feedback that would warn of the changes in
the marketplace. Even when Dell finally read the signals (in some cases only after
outside analysts had pointed them out publicly), its business processes appear not
to have had the ability to make the necessary adjustments.
Most analysts today agree that Dell’s failure could be attributed to several specifics, chief
among which were the following:
 Dell failed to recognize that the general consumer was transitioning to laptop
computers, and so Dell remained focused on desktop computer sales.
 Hewlett-Packard and other computer manufacturers were able to achieve
and exceed the efficiencies of Dell’s supply chain and direct supply model.
Competitors retained major sales in the retail and other channels, giving
them the advantage of cumulative volume through multiple channels as
volume is an important element in the cost calculus of PC manufacturing.
 Dell remained focused on the U.S. market, and failed to recognize that the
international market was rapidly catching up to the U.S. market in size and
importance. Again, competitors were able to build volume in those markets
that positioned them to exceed Dell.
 Dell’s response to its cost and product disadvantage was to continually
ratchet margins down to meet the competition, which it was unable to offset
by any further saving in operational expense. Eventually, the point was
reached when the gross margin slipped below operational cost, and the model
broke completely. The company was forced, from a weak position and by
2006—very late in the cycle (some think too late)—to rethink their strategy
and reorganize.
 After the first round of reorganization, by early 2008, Dell’s recovery is faltering.
It appears that the company has not been able to fully embrace the
essential transformation they needed to make, and they remains mired in
problems.
Example #7: The Power of Smart Decisions behind Business Processes
To understand the idea of smart decisions, consider the case of Parker Hannifin, a U.S.-
based Fortune 500 manufacturer of motion and control equipment (Aeppel, 2007). In
2001, a long-time employee, Donald Washkewicz, became president of the company. He very
soon realized that the company’s pricing policies were flawed: managers would simply pitch
their prices to earn the company a gross margin of 35%, considered an industry standard.
Washkewicz realized—with the help of outside consultants—that this failed to capture the
value that the company was adding for their customers. He began to understand that by
being able to price according to a formula that recognized this value, he could transform the
company. It took a major reorganization of the company’s business processes (and a very
significant change of culture) to engineer this capability. The reengineered business
processes separated price, tying it to a system of intelligence gathering to accurately
determine the appropriate price for a given product.*
This was not easily achieved. The old pricing rules were deeply buried, hardcoded in
computer systems, many of them as recently deployed as the 1990s. But management
persevered and eventually succeeded, despite the impediments created by automation itself.
Today, Parker Hannifin researches the pricing of each and every product it manufacturers,
and tracks feedback on those products from its customers over time to constantly validate
and adjust the price. It works closely with its customers in helping them understand the
price/performance advantage of its products compared to the competition, and constantly
improves the products in ways that can save the customers money.

At the same time, Parker Hannifin refined its other processes, including its
“buy side” value chain (how it purchases products from suppliers), and adopted lean
manufacturing. The results have been dramatic.

Parker Hannifin today is a leader in its industry, in fact a leader in almost any
category of U.S. business. Between 2002 and 2007, its stock rose 160%, exceeding
twofold the rise of the high-tech NASDAQ, and eightfold the growth of the Dow
Jones Industrial index. Other key numbers:

Revenue—Just topping the $5 billion mark in 2001; analysts estimate $12

billion for 2008.

Profits—In 2002, the company achieved a profit of $130 million; in 2008,

analysts estimate profit will be closing in, on $1 billion.
Fortune 500 Ranking—In 2001, the company was ranked 330; in 2008, it
was ranked 247.
Parker Hannifin took several of the major steps necessary to create smart
processes. They separated the business decisions from the business processes,
tied specific targets of performance to the business decisions, and implemented
the means to measure that performance. In their case, the focus was the added
value of the product to their customer. Not only did they determine this value,
but actively worked with the customer to understand this value, and worked
with the customer to improve the value by improving the design of the product.
Today, Parker Hannifin continues to monitor the value of products to ensure
that the price remains competitive while delivering a good return to the
company. As a company, it has achieved some of the highest gross profits in
their sector of industry.
How the Decision Model Advances BDM
Business processes that meet the criteria of being smart and agile are those for
which the business decisions have been separated from the business process,
are represented in Decision Models, whose impact on the business is monitored,
and whose business logic is adjusted to remain aligned with business objectives.
Definition of BDM
The practice of managing smart, agile decisions is called Business Decision
Management (BDM). BDM is often referred to as Enterprise Decision
Management—these terms can be used interchangeably.
Figure 4.10 summarizes the three elements of BDM: business motivation,
business logic, and business metrics.
These three elements interact to create “smart” business systems, which is the
goal of BDM:
 Business Motivation: This is the general business plan, and the specific
business objective/s within that business plan, that the business decision is
meant
to implement.
 Business Metrics: These are the measurements and time periods that are
set by the business objectives, and that must be achieved by the business.
These metrics are arrived at in the business planning phase, and may be
supported by predictive modelling techniques.
 Business Logic: This is the logic underlying the business decision that is
implemented to achieve the business objective. This business logic is
formulated to best deliver the business metrics set by the business
objectives. The role of the Decision Model in BDM is to maintain a stable,
normalized and complete representation of that logic.
Establishing BDM Questions:
Early adopters of the Decision Model have begun to adopt best practices for
1. Is Decision Model a procedural or declarative solution? Why?
BDM. From an organizational perspective, doing so requires seven important
2. Explain the insights you gained, which is related with our present and
considerations:
previous topics, from Dell’s case which was discussed above.
 Consideration #1: Recognize business decisions as key business assets that
3. Discuss briefly the “value pricing strategy” which was also used by Parker
drive business processes. Success begins with the recognition that business
Hannifin.
decisions and corresponding business logic should be made explicit and
4. Describe the characteristics of a business process that is agile and smart
agreed upon by relevant business stakeholders.
5. Consider a game of American baseball. What parts of the game are procedural
 Consideration #2: Adopt the Decision Model as a separate, cohesive
and what parts are declarative? What is the role of the official rulebook?
representation for the detailed business logic behind business decisions. The
Decision Model provides a graphic representation of this business logic. The
Rule Families provide a means to explore the complete logic behind the
Decision Model in a clear and simple manner. In other words, the Decision
Model can be used to achieve a shared understanding of the business
decisions and reach a consensus around them.
 Consideration #3: Define the active role of business people in creating,
changing, and governing the important Decision Models.
 Consideration #4: Use the Business Decision Management Maturity Model
(BDMM) to develop a road map toward implementation of BDM. This will
help to reduce risk and to maximize the return on investment.
 Consideration #5: Establish a center of excellence for BDM to outline
methodology, deliverables, standards, and training.
 Consideration #6: Evolve the current state of business requirements to
include Decision Models
 Consideration #7: Prepare the technology. Select a modelling tool for
creating and managing important Decision Models. Invest in specific
technology for automating selected Decision Models. Consider technology to
provide the necessary modelling tools to project performance and analytic
tools to track the performance of business decisions. Start to build the
architecture to support BDM.