BPM: Knowing the Future Means Knowing the Past (Part II of II)
See Part I for a background on BPM development.
As a result of Business Process Management evolving over two states it cannot
only be defined from one perspective -- below are two definitions catering to
both the business and technology perspectives of BPM:
BPM is a management discipline concerned with managing change to improve
business processes that is cross functional in nature and makes extensive
use of technology to model processes, analyze the model, automate the processes
and measure and optimize process performance.
BPM is unifying the previously distinct disciplines of Process Modeling,
Simulation, Workflow, Enterprise Application Integration and Business to business
integration into a single organizational platform or infrastructure.
If we consider the two definitions above we see three core focal points in
defining BPM, as a much confusion has occurred when defining BPM.
The first focal point when defining BPM is that it is a management discipline
-- more focused on the business side of the organization, where issues such
as organizational change management are taken into account. However, as many
of us have realized one is not able to embark on a BPM journey without technology
playing an enabling role.
The second focal point when defining BPM is that it is a new software technology
-- this is not entirely true as the underlying concepts and principles that
the Business Process Management Suites unify under a single organizational platform
or infrastructure have existed for many years, the only difference now is that
they have been packaged into a single offering.
The third and final focal point when defining BPM is that it is a new type
of implementation. This is probably where the greatest progress has been made
with regards to BPM, as businesses are now able to drastically reduce if not
eliminate the round-tripping aspects of business application implementation.
Through the ability that the BPMS's now provide businesses are able to model
a business process and then have the preconfigured application rendered for
business confirmation of the requirements within minutes, allowing for a more
iterative nature of business requirements gathering and the true realization
of Model Driven Architecture.
In the final phase of this business evolution we will consider Business Process
Re-engineering (BPR) as compared to Business Process Management. The initial
point of comparison will consider the current business processes within the
organization. From a BPR stand point the thinking was that the processes are
fundamentally flawed and an entirely new set of processes will need to be engineered;
whereas the BPM thinking is more in line with TQM, one would take the current
processes as they are and automate them to continuously and incrementally improve.
One key aspect to bear in mind here is that one should begin automating ones
processes as soon as possible -- as the realization of MDA within the BPMS now
provide one the ability to very quickly rectify bottlenecks or waste within
a process there is no longer a need to conduct large scale process analysis
engagements before beginning with automation.
The second point of comparison is that BPR initiatives conducted workshops
and joint application development sessions (JAD's) with business users, the
primary goal being to produce a document containing all the organizations business
processes. BPM initiative conduct workshops and JAD's to ensure that the business
processes become a living component of the organization, as models are now documented
within technology to enable MDA and the ability to immediately assess from a
business application aspect that all the business requirements are in fact realized.
The third comparison is that BPR defined the organization into silo's and is
function based whereas BPM defines the organization end-to-end and across functions
and is results based.
The fourth comparison is that BPR engagements typically took anything between
6 to 24 months to provide any form of return on investment whereas BPM engagements
can now show return on investments in as little as 90 days.
The fifth comparison -- in BPR engagements IT and business collaboration is
optional whereas in BPM engagements collaboration is critical, as BPMSs are
intertwining the Business and IT roles to provide adaptability and agility to
The sixth comparison is that BPR was fundamentally focused on cost reduction
whereas BPM is focused on asset optimization -- or the ability to increase capacity
while still utilizing the same number of resources.
The seventh comparison pretains to the nature an engagement is implemented;
traditionally and in most instances today a waterfall or system development
lifecycle approach is adopted. BPM engagements should be conducted in an iterative
manner, with the approach being aligned to rapid application development.
The final point of comparison is that within BPR engagements workflow and enterprise
application integration were utilized each within a standalone environment.
With BPM there is the advent of the BPMS which provides a single organizational
platform that unifies previously standalone environments.
Now that we have established the differences between BPR and BPM we will turn
our attention to three of the core process methodologies that have been developed
over the years.
The first methodology we will adress is Six Sigma; its primary focus
is that of reducing variation, the end result being standardization. The manner
in which BPMSs cater to reducing variation is through simulating processes.
BPMSs can create multiple scenarios against which simulations can be run and
then produce graphical and tabular representations of the results all at a touch
of a button. These results are then interpreted and the necessary adjustments
made in order to ensure that the process variation is minimal and standardization
The second methodology is Lean Engineering; its primary focus is to
remove waste and ensure that the flow time of a process is as short as possible.
BPMSs achieve this through their ability to monitor the flow of the process
in real-time, highlighting bottlenecks or activities that do not provide value.
BPMSs also cater to Lean Engineering in their ability to distribute work via
push or pull mechanisms.
The third methodology is The Theory of Constraints; primary focus is
to elevate or exploite constraints and in so doing ensuring faster throughput
and increased capacity. The end result of this methodology is to determine the
maximum amount of volume that can be pushed through a given process before the
process reverts to a chaotic state. The mechanism utilized by BPMSs to enable
this is Service Level Agreement (SLA) escalation. BPMSs provide the ability
to specify an SLA per activity. Should these SLAs not be met escalation procedures
can be activated, ensuring that the constraints are addressed sooner rather
To conclude this section of BPM we will discuss Business Process Modeling Notation
otherwise known as BPMN. BPMN was first initiated by the Business Process Management
Initiative whose core focus was to develop a modeling notation that would be
readily understandable by all stakeholders, these being business users, business
analyst, technical analysts and developers. BPMN plays a key role in the realization
of MDA and as a result I will briefly describe the core element set.
As graphically illustrated in Figure 2 above the core elements of BPMN are:
Flow Objects: signal the start or end of a Business Process Diagram (BPD),
what tasks and activities are conducted within the BPD and how the flow is
routed. Flow objects are comprised of:
Events - An event is something that "happens" during the course
of a business process. These events affect the flow of the process and usually
have a cause (trigger) or an impact (result). Events are circles with open
centers to allow internal markers to differentiate different triggers or
results. There are three types of Events, based on when they affect the
flow: Start, Intermediate, and End.
Activities - An activity is a generic term for work that the company performs.
An activity can be atomic or non-atomic (compound). The types of activities
that are a part of a Process Model are: Process, Sub-Process, and Task.
Tasks and Sub-Processes are rounded rectangles.
Gateways - A Gateway is used to control the divergence and convergence
of Sequence Flow. Thus, it will determine branching, forking, merging, and
joining of paths. An element placed within the diamond shape indicates the
type of behavior control.
Connecting Objects: indicate the direction of the flow of the process within
the BPD and are comprised of:
Sequence Flow - A Sequence Flow is a solid line with a filled triangular
arrow-head used to show the order that activities will be performed in
Message Flow - A Message Flow is used to show the flow of messages between
two participants that are prepared to send and receive them. In BPMN,
two separate Pools in the Diagram will represent the two participants
(e.g. business entities or business roles).
Association - An Association is a solid line with an open arrow-head
used to associate information with Flow Objects. Text and graphical non-Flow
Objects can be associated with the Flow Objects.
Swimlanes: these elements act as containers for organizations, departments
or roles and are comprised of:
Pool - A Pool represents a Participant in a Process. A Pool can contain
one or more swimlanes however; it can also act as a "swimlane"
and a graphical container for partitioning a set of activities from other
Pools, usually in the context of B2B situations.
Lanes - A Lane is a sub-partition within a Pool and will extend the
entire length of the Pool, either vertically or horizontally. Lanes are
used to organize and categorize activities.
Artifacts: provide the ability to provide metadata to the BPD and are comprised
Data Object - Data objects are considered Artifacts because they do
not have any direct effect on the Sequence Flow or Message Flow of the
Process, but they do provide information about what activities are required
to be performed and/or what these activities produce.
Text Annotation - Text Annotations are a mechanism for a modeler to
provide additional information for the reader of a BPD.
Group - A grouping of activities that does not affect the Sequence Flow.
The grouping can be used for documentation or analysis purposes. Groups
can also be used to identify the activities of a distributed transaction
depicted across more than one Pool.
With the business evolution concluded I will now describe the technology evolution
and how this evolution has occurred from standalone applications to workflow
to business process management.
In describing the technology evolution I will measure each one of the components
of this evolution against its core focus, application type, organizational impact,
reporting capability, ability to update and adapt processes and its MDA capability.
The first component of the evolution is standalone applications and with these
applications I have also grouped imaging/document management applications. If
we look at the core focus of the standalone application it was to define a sequence
of events and these would traditionally be either manual or custom applications.
Standalone applications organizational impact was very much functional or silo
specific as a result of the application being a point solution. Standalone applications
reporting capability were very basic and in most instances one had to wait for
the end of the month for batch reports which resulted in a very reactive approach
to problem solving. In terms of its ability to update and adapt processes this
would take several weeks if not months as custom code had to be developed and
the full System Development Lifecycle needs to be followed. From a model driven
architecture perspective standalone applications did not have any modeling capability
and so could not realize MDA.
The second component of the evolution is workflow applications, which core
focus is the routing of tasks. It began from the imaging and document management
applications where organizations once had their documents in electronic format.
They soon realized that they needed to route these documents to assessors, decision
makers, etc. From an application type perspective workflow applications were
fairly tightly coupled between integrated applications as custom Application
Programming Interfaces (API's) were utilized. Workflow applications organizational
impact was as per standalone applications as these solutions were still very
functional or silo specific. The reporting capability still resulted in a reactive
approach to problem solving however the ability to generate reports in shorter
time periods did improve. Workflow applications ability to update and adapt
processes would take several weeks as once again custom developed code would
be manually created and would then need to go through the testing lifecycle.
From a MDA perspective workflow applications had some modeling capability although
there would still be a significant amount of custom development that would be
required to be undertaken in order to meet the business requirements.
The final component of the evolution is business process management, which
focuses on the process of lifecycle management -- taking into account the business
processes, escalations, SLA's etc. The application type from a BPMS perspective
utilized standard adapters when conducting enterprise application integration
and for business to business integration web services. Its organizational impact
is across the value chain and enterprise wide thereby ensuring that the processes
are managed from inception to completion. BPMS have the ability to conduct dashboard
and real-time reporting, resulting in the organizations ability to be proactive
in problem resolution, as soon as issues or errors occur with a process these
can now be rectified. This leads to the ability to identify, avoid or mitigate
issues before they occur. BPMS's ability to update and adapt to processes is
extremely high and can in most instances be conducted within hours if not minutes.
BPMSs have at its core business process modeling and almost all utilize BPMN
as their modeling notation of choice. With business process models at its core
BPMSs are able to truly realize MDA.
This then concludes our technology evolution and now with both the business
and technology evolutions described it is time to discuss the missing link and
really the glue that brings business and technology together in this evolution
cycle -- model driven architecture.
Figure 3 above indicates the model driven architecture continuum and as we
move from left to right the ability to execute against a model increases along
with the ability to generate code automatically.
Let's start on the left hand side of Figure 3 at the code only stage; this
typically occurred in the assembler and mainframe days when pages and pages
of code were written in one monolithic application. This naturally made maintenance
and enhancements to the code extremely challenging and led to code visualization
where code began to be modularized or packaged, becoming the module that one
could depict a diagram of broken code with.
We now find ourselves at the round-tripping stage and amazingly almost 80 to
90 percent of organizations are still at this stage of the continuum. They first
send in the business analyst who models a business process, it is then passed
on to a systems analyst who models this business process in terms of technology
and it is finally passed onto the developer who produces an application which
in most instances may not be 100% correct as the market may have changed in
the time that elapsed.
With the advent of workflow applications we started to move to the model centric
stage and began to aquire a better understanding of the concept of a model where
one could graphically model the process and code stubs would be automatically
generated. However, not all the requirements were met. As a result one still
had to customize 70 to 80 percent of the application.
The final stage of the model driven architecture continuum is where BPMSs are
today. One can merely model a business process and have a preconfigured application
automatically generated, thus eliminating the round-tripping effect and meeting
the business requirements to within 80 to 90 percent. The 10 to 20 percent of
customization still required consists of integrating into existing line of business