2. How did we get here?
BPM is an old discipline that allows you to model the
organizational structure, define the business processes,
and show their interactions.
The design and automation of business processes even
warrants its own field of study, known as BPM
(Business Process Management).
Traditionally taught in business schools, it is put into
T diti ll t ht i b i h l i ti t
practice with varying degrees of success.
Hammer and Champy, the authors of the widely read
py, y
“Reengineering the Corporation”, focused their attention
on business processes as a root cause of inefficiency
and also the source of potential competitive advantage.
p p g
3. Over the last two decades, the public and private
sectors have been giving increasing attention to
business processes.
This interest grows out of the requirements to
streamline business operations and overhead,
consolidate organizations, and save costs.
What i diff
Wh t is different today i the novel use of computing
t t d is th l f ti
technology to drive the analysis and automation of
business processes.
Hence, the level of interest and the marketing
hyperbole around BPM has reached a crescendo.
4. Innovations in technology such as XML, Web Services,
Service Oriented Architecture, Service Catalogs,
, g ,
component-
component-based deployment, and information
messaging have fueled the current interest in BPM.
Vendors have developed Business Process Management
p g
Systems (BPMS) that provide the fine-grained
(BPMS) fine-
integration of systems and data needed to automate
business processes.
BPMS li k people and systems, manages information
links l d i f i
access and transformation, handles exceptions, and
orchestrates the flow of the process.
That
Th t was th l t d
the last decade.
d
5. Today, organizations are looking to BPM to help solve
problems, like:
To be competitive, a supplier needs to cut its costs
for fulfilling customer orders, by 70 percent.
A pharmaceutical company seeks to extend the
patent life of its drugs by bringing new products to
market, one month earlier.
A government agency, forced to reduce staff by
agency
30 percent, must find a way to consolidate and
streamline its unemployment benefits services.
Personally accountable under the Sarbanes-O l
P ll bl d h Sarbanes-Oxley
S b
Act, company executives need to control and
verify the process used to produce financial
statements.
6. As an example, Gartner announced that BPM "wins the
'Triple Crown' of saving money, saving time, and adding
p g y, g , g
value.“
Is this promise being fulfilled?
BPM technologies are becoming more mature and BPM
does have the potential to deliver significant value.
But there are still elements that are missing that limit its
e ect e ess
effectiveness.
Thus, many Developers and Business Analysts still find
themselves asking the basic questions:
What is it?
Why should we care?
7. This presentation provides a high-level overview of BPM
p p high-
g
and where it is today.
It also touches on some of the core technologies and
standards.
Its focus is on the four specific “Challenges” facing BPM
and they are aligned to the four phases of the typical
application development life cycle.
Discovery
Design
Development
Deployment
8. The Discovery Challenge
Typically, Business Analysts, needing to discover the
yp y, y , g
current state of things, try to visually represent the
various processes of the business.
The approach taken by many BPM products fails to
pp y y p
address this challenge adequately.
They employ a drawing “metaphor” in which a
Business Analyst or Developer sketches the process
using a palette of standard icons.
l f d d
This assumes the existing process is known in
advance.
Most organizations however, simply do not know their
end-to-
end-to-end processes accurately or in detail.
Their process knowledge is tacit and decentralized—not
p g decentralized—
explicit and centralized.
9. How can you discover,
how a business operates?
h b i t ?
Classical manufacturing processes have been analyzed
extensively in quantitative and qualitative terms.
Discovering general business processes is somewhat
less straightforward. You can adopt either a Top-down
Top-
or Bottom-up approach.
Bottom-
10. The Top-down approach
Top-
p pp
The Top-down discovery approach typically begins with
Top-
the organization chart. It lists the responsibilities of
each department in the organization and identifies the
high level processes that support th
hi h-l
high- l th t t these responsibilities.
ibiliti
The advantage of this approach is that it provides a
broad, organizational perspective.
Its disadvantage is a lack of detail and a questionable
degree of accuracy.
11. The Bottom-up approach
Bottom-
The Bottom-up approach begins by interviewing
Bottom- p pp g y g
employees about their day-to-day activities and attempts
day-to-
to integrate this information into coherent end-to-end
end-to-
p
processes.
This approach can be extremely accurate but you can
easily get lost in the details.
These processes are then decomposed into lower-level
lower-
processes, which are decomposed further, until the
lowest level is reached.
12. The Hybrid approach
y pp
Some hybrid Top-down/Bottom-up approaches seek to
Top-down/Bottom-
achieve the advantages of both methods.
methods
Since no two organizations are exactly alike in how they
operate, different discovery methods are probably more
appropriate.
Further, a single capture of business processes is likely
to be woefully inadequate. As is so often the case, later
discoveries inform earlier ones, and an iterative
discovery methodology that continually enhances and
updates the processes may yield better results.
Regardless of the methodology followed, there is of
g gy ,
course the key requirement that management
support and drive the business-process discovery.
business-
Without this support, the chance of success is minimal.
pp ,
13. Business Co s qu
us ss Consequences
s
As awareness of the importance of business processes
grows,
grows many are attempting to capture their current-
current-
state business environment. They form workshops of
business users, sketch the processes, and try to achieve
consensus within the team.
Unfortunately, they have no way to ensure the accuracy
or completeness of the resulting diagrams. Often the
underlying complexity of existing business processes is
oversimplified by such workshops.
i lifi d b h k h
Much of the important meta-data about the processes,
meta-
such as cost, cycle time, and information flow, cannot
be
b easily fit into “Visio” diagrams. Moreover, the
il i t “Vi i ” di M th
information contained in the processes cannot be easily
changed or analyzed effectively in these diagrams.
14. Technical Consequences
a Co s qu s
Accurately capturing the current or “as-is” process is a
“as-
prerequisite for defining the structure and rules of the
“to-
“to-be” process.
Without this level of understanding, a BPMS
“Developer” may produce a sub-optimal solution with
Developer sub-
the tool or, worse, a solution to the wrong problem.
BPMS tools were designed to “automate processes”, not
to analyze business.
The process automation, implemented using BPMS may
therefore, fall short of the true goals of the business.
Why not ask the Business Analysts to use the BPMS
products to discover and analyze business processes?
This would seem to solve this problem.
15. Unfortunately, most BPMS products have been designed
for
f use b D
by Developers, not f th b i
l t for the business.
They provide few, if any, capabilities for process
discovery, defining meta-data, simulation, or analyzing
meta-
process costs or cycle times.
16. The Design Challenge
g g
The ultimate purpose of BPM is to improve and optimize
the
th operations of an organization.
ti f i ti
Its scope, necessarily, comprises not a single process
but all processes across the organization.
p g
Unfortunately, most BPMS products are designed to
work on one process at a time. The “Developer” draws
the process, adds implementation constructs, and then
executes the process.
There is no way in these tools to: look across multiple
processes,
processes examine process interconnections make
interconnections,
comparisons, or perform analysis.
17. Process Laboratory
What is needed is a “process laboratory”, where
Business Analysts can collaborate exploring the process
collaborate,
space, testing ideas, measuring, analyzing, and
comparing processes, and generally performing
business thought experiments and scenarios.
g p
This laboratory would give analysts the tools to design
new processes, view the processes from multiple points
of view, extract analytical reports across the processes,
generate system requirements, and perform simulation
i d f i l i
or “what if” experiments.
It would allow them to create centralized reusable
processes th t can b i
that be invoked b processes in different
k d by i diff t
operating units
Obviously, one key element in such a laboratory is a
“process language” to express ideas
ideas.
18. Process Language
g g
This “process language” would be used to define the
basic entities of business processes (processes
(processes,
participants, activities, links, etc.) and the rules for their
operation and interaction.
A standard process language would allow customers to
use products from different vendors for defining and
implementing business processes.
Processes defined in one product could be executed on
another product.
Over the past three years, various organizational groups
have made numerous attempts to define standards for
p
Web services and business processes.
19. Organizational Groups
g p
The relevant organizations are:
Workflow Management Coalition (WfMC)
W kfl M t C liti (WfMC)
Object Management Group’s - Business Process
Management Initiative (BPMI)
g (BPMI)
World Wide Web Consortium (W3C)
(W3C)
OASIS.
OASIS.
20. BPEL
An important XML-based language for defining business
XML-
processes is the Business Process Execution Language
for Web Services (WSBPEL, BPEL4WS, etc.)
The underlying assumption behind the BPEL
specification is that business processes will be
ifi ti i th t b i ill b
composed of a series of interacting Web services.
Since WSDL (Web Services Description Language) is the
( p g g )
natural language for describing Web services, BPEL is
an extension of WSDL.
Each activity in a BPEL process is implemented by a
Web Service, which is defined by its port types,
operations, and messages.
21. In BPEL, a business process is composed of a central
process engine that interacts with a set of business
partners.
process
partner message message partner
engine
Each Web-Service operation is performed either by
Web-
one of the partners or by the central process engine
itself.
itself
The process engine communicates with its partners by
exchanging messages. The process engine and
partner send messages across a communications
channel called a “service link.
22. To make this more concrete, let’s consider a stock broker
interacting with a stock exchange (Stock B k P
i t ti ith t k h (St k Broker Process).)
buyerLink
stock
process
exchange
role: role:
buy requestor buy service
stock
stock order
transaction
port type
port type
23. The service link is a bilateral contract between the
Stock Broker “ “process” and the “
” “stock exchange” that
”
defines the services each offers to the other.
The process and the partner play different roles across
the service link.
The process, in its role, exposes a WSDL port type—
type—
that is, a set of operations that it agrees to offer.
Similarly, the partner, in its role, exposes another set of
operations.
ti
24. Having defined the conceptual framework for partner
interaction,
interaction BPEL then specifies the building blocks of
processes: activities, flows, links, data containers, and
assignment operations.
These are defined in terms of their XML structure but
structure,
without a graphical model for representing them.
BPEL also addresses technical constructs required for
proper execution of the business process
process.
These include correlation, fault handling, and
compensation.
25. Correlation - is the technique used to create
associations between process instances by using the
data fields as identifiers.
For example, a field “order number” might be used to
correlate a purchase order and a purchase-order
purchase-
acknowledgment.
Fault handling and Compensation specify the
Compensation
procedures to be followed when an error occurs in the
process.
For long-running processes, the idea is to “undo” a
long-
complex series of activities with a compensating series
of activities.
26. For example, if you want to specify that activity 1 must
precede activity 2, you have two ways to d so.
d ti it 2 h t t do
1. Use the structured activity called “sequence.”
2. Connect these activities through a link within a
2
flow.
The BPEL specification provides no hints as to when to
use one technique or the other
other.
In BPEL, each process is an assemblage of Web
services, but the process is itself a large-scale Web
large-
service. This fractal-lik approach enables unlimited
i Thi fractal-like
f t l h bl li it d
composition and decomposition of Web services.
27. BPEL is a significant achievement, but it has several
weaknesses that limit its widespread adoption:
It addresses only processes composed exclusively
of Web services.
It h no graphical rendering. To date, no available
has hi l d i T d t il bl
products generate process graphics from a BPEL
document or vice versa.
It does not include a framework for performing
Top-
Top-down design—that is, for creating a process in
design—
a series of layers with successive refinement.
It provides no capabilities for process analysis
analysis.
It is a vendor-driven process definitions language
vendor-
that has not yet been reflected in a royalty-free
royalty-
standard published by a universally recognized
standards group.
28. The major competitor to BPEL as a process language
based on Web services is BPML (Business Process
Management Language).
Both BPEL and BPML are ultimately based on the π
calculus,
calculus but the Business Process Management
Initiative introduced BPML two years earlier than BPEL.
BPEL has actually incorporated many BPML concepts
and,
and with the support of Microsoft and IBM, it has the
IBM
advantage of industry momentum.
Microsoft, IBM, and BEA Systems have introduced BPEL
in their products, but as expected, with proprietary
products expected
language extensions and some tools to aid in process
design.
29. Business Consequences
The goal is to translate the process information
gathered i Discovery into a standard process language,
th d in Di i t t d d l
such as BPEL. But Business Analysts can’t use BPEL, at
least not in its current form.
Given a BPEL process d fi iti
Gi definition, you will find it nearly
ill fi d l
impossible to disentangle the business logic from the
details of the implementation.
The business semantics are obscured by the technical
details required for execution.
What is lacking is a way to layer BPEL, to filter out such
technical constructs as fault handling correlation and
handling, correlation,
transaction management.
30. It should be possible for a Business Analyst to use a
process llanguage to d i the business logic.
t design th b i l i
Once the business logic is mapped out, a Developer can
insert the technical constructs.
Business Analysts generally prefer a visual way to
design processes.
They would also likely benefit from a way to design
processes ffrom the Top-d
h Top-down, beginning with high-l
b h high-level
h h l
processes and refining them to low-level processes.
low-
31. Technical Consequences
In many cases the Business Analysts will design the
business process using an analysis tool.
tool
If BPEL is not used by the business process analysis tool
as well as by the BPMS, then a custom mapping will be
required to translate between the XML dialects of the
two products.
In its current form, BPEL will be of limited use since it is
designed for processes that are implemented using Web
services.
A key goal of business-process design is to define and
business-
communicate requirements.
requirements
For example, suppose a new system will be used in
multiple processes, supporting different users and
systems performing different functions.
32. Ideally, the business processes are defined in such a
way that the functional requirements can simply be
extracted from the process definitions.
If a new system performs 25 activities across 17
processes,
processes then these activities can be summarized by
an appropriate query.
This procedure is precisely analogous to extracting data
from a relational database. Unfortunately there is
database Unfortunately,
currently no searchable knowledge base of BPEL
processes.
Moreover,
Moreover since BPEL has no notion of “participant” or
participant
“actor” to identify the proposed system, it will not be
able to support this important goal of the process
laboratory.
y
33. The Development Challenge
A successful development project is the result of many
favorable conditions, one of the most important being
conditions
close collaboration between Business Analysts (define
the needs of the business) and Developers (implement
systems that meet these needs)
needs).
Business Analysts and Developers are driven by
different goals, speak different languages, and work at
different l
diff levels of precision.
l f i i
In the domain of BPM this gap is manifested by
automated business processes whose execution does
p
not match the original business requirements.
Business Analysts typically communicate business needs
(in the form of requirements) to the Developers who
Developers,
may interpret the needs rather differently.
34. Using a BPMS tool, the developers implement the
automated solution as they understand it.
y
Why not have the Business Analysts define the business
process using the BPMS tools?
This is not realistic since BPMS products are generally
intended for use by developers, not by Business
Analysts.
They e ab e de e ope s to c eate tec ca co st ucts,
ey enable developers create technical con-structs,
not business requirements.
Tools based on UML (Unified Modeling Language) are
sometimes suggested as an alternative. UML is well
gg
suited for developers who need to design class diagrams
and lay out the interactions between method calls.
The UML suite of diagrams is, however, not so well
g
suited for Business Analysts working with business
processes.
35. Business Consequences
The business consequences of the gap between
Business Analysts and Developers are:
increased risk of failure
longer lead times for development.
l l d ti f d l t
The Standish Group discovered:
31 percent of all software development projects are
cancelled before they are completed.
53 percent are either not completed on time, budget,
or fail to deliver the projected functionality.
16 percent of projects are completed on time and on
budget.
budget
36. Technical Consequences
The classical requirements documentation leaves
q
considerable room for interpretation.
It rarely provides the level of precision needed by IT
Developers, who need to know:
D l h dt k
Each activity that must be performed by the system
The step-by-step control logic of the enveloping
step-by-
business process
The specific data required at each step of the
process
The business rules that govern changes to the data.
37. This lack of precision leads to misunderstandings
p g
between the analysis and the development teams.
Redefining requirements, redesigning, and recoding
midstream are expensive and time-consuming.
p time- g
What’s missing is a seamless way to integrate design
and development.
Business Analysts should create process designs at the
business level within their process laboratory and then
export these designs in XML form to the BPMS.
Developers will then refine the design, adding the
p g , g
technical constructs needed for implementation.
This eliminates any ambiguity about the requirements
and business need.
38. The Deployment Challenge
The whole point of automating business processes is to
p g p
improve operations—in cost, time, or quality.
operations—
Once a process has been developed and deployed, how
can we know if it is meeting the intended goals?
g g
We know how to instrument IT systems and monitor
them with a high degree of precision.
These statistics, however, do not generally provide a
business-
business-process context around this information.
The challenge is to aggregate and present execution
data at the business-process level.
business-p
Gartner coined the term business activity monitoring
(BAM) for this capability
39. Business Consequences
Without BAM, operational managers have no way of
, p g y
determining whether the processes, for which they are
responsible, are meeting their objectives.
For example, they will not be aware that the cost of the
p , y
order fulfillment process has increased 20 percent
above average, or that the time required for handling
new benefits claims declined by 10 percent, or that the
outage optimization process for web portal is in trouble
trouble.
Lacking this information, executives have no way to
determine which action to take.
A way to aggregate execution statistics i process
t t ti t ti ti in
context would help the business manager better
manage these types of exceptions.
40. Recently, several vendors have developed BAM
y, p
products, but in many cases they are “discrete event
monitors” that lack overall process context.
To achieve true process context, you must link
p ,y
individual activities into a process to provide information
on what is done in that process and by whom.
For example, you can group process instances by
g
geography, customer, or organization.
h
Finally you need to “chain” processes that logically
belong together, such as an order process and an
invoice process.
i i
All this information is then summarized and presented
on an executive dashboard on the enterprise portal.
41. Technical Consequences
Most organizations recognize the importance of BAM
g g p
but have no effective way to collect, aggregate, and
analyze execution statistics.
Often it is done in an ad hoc manner, in which reports
, p
from legacy systems are combined into a data
warehouse from which summary reports can be
generated.
It is possible to determine quite precisely the utilization
bl d l h l
of each disk drive, server, and network component in
the IT environment.
From such statistics, h
F h t ti ti however, you will not know which
ill t k hi h
resources need to be expanded, consolidated, or
upgraded to support the business objectives.
42. For example, you simply may not know whether or not
p y py y
increasing the capacity of a specific disk will affect the
order-fulfillment-
order-fulfillment-cycle time.
With BAM, we come full cycle.
, y
The results of process monitoring will enable the
rediscovery and redesign of business processes.
Executives will know about hotspots that demand their
immediate attention. In the longer term, the execution
will keep pace with the business needs and the process
designs.
43. This figure summarizes this life-cycle concept.
life-
analysis
Process
Requirements
Maps
discovery design
BAM XML Imports
p
Dashboards
execution
44. Conclusion
Any enterprise can be viewed as the sum of its business
y p
processes.
Each process delivers value to customers, suppliers,
employees, or other stakeholders.
p y ,
BPM, the discipline for enabling and automating
business processes, is in a period of rapid growth and
will fundamentally change the way computing power is
g g
applied in organizations.
l d
Whereas BPM has already delivered considerable value
in many companies, the components of the full BPM
solution are still evolving and are the subject of ongoing
l ti till l i d th bj t f i
research and development.
45. One noteworthy advance has been BPEL, an XML-based
XML-
language for describing business processes composed
of Web services.
This presentation has focused on four immediate
challenges:
1. Process discovery is the beginning of any BPM
solution and is necessary to ensure that the
l ti di t th t th
solution matches the real business needs.
2. Business Analysts lack a p
y process laboratory in
y
which to design, analyze, and simulate business
processes.
46. 3. Integration is missing between the tools used for
g g
business process design and the tools used for
execution.
4. BPM generates valuable performance statistics from
g p
executing business processes. Businesses need to
monitor these execution statistics, organize them
into their process context, and present them in the
form of alarms, reports, and executive dashboards
alarms reports dashboards.
There has been significant progress in BPM in this
decade and many challenges will, and are being
addressed in the future
future.
Others may prove less tractable and will take a little
longer to solve.
47. Once this happens, for the first time we will have a
complete, closed-
complete closed-loop approach to business processes:
from conception to execution and back.
This gives executives the ability to design their business
processes, automate them, and judge quantitatively
how well they are doing against their plan.
With this information, they can then redesign or
optimize the processes.
Gradually, the technologies and techniques described
here will change the way businesses and governmental
agencies apply technology.
g pp y gy
In the words of Howard Smith, “Third-wave business
“Third-
process management methods and systems will utterly
transform the way companies conceive, build, and
y p , ,
operate automated systems.”
