Business Process Management (BPM) is a natural and
holistic management approach to operating business that produces a
highly efficient, agile, innovative, and adaptive organization that far
exceeds that achievable through traditional management approaches.
Steve Towers, BPMG.org
Easy for you to say Steve, but getting to that
organizational state has become big business and we seem to be in a
situation where a large number of companies are pushing in one limited
direction. This is starting to subvert the original intent and creates
the potential for failure – a failure based on the idea that the end
game is simply one of more I.T. applications.
Most of the vendor (hoped for) opportunity is for
newly implemented I.T. systems. This allows for multiple chances for the
introduction of other services such as SOA and enterprise this and
enterprise that. The competition for I.T. dollars is however getting
more and more intense and (as usual) relying on an expectation of
implementing an I.T. application takes away from much of the potential
benefit of BPM.
This pressure for new systems overshadows the
multiple business opportunities for innovation and productivity that is
available from the initial steps associated with BPM. The simple to use
(and in many cases free) diagramming tools that are the front end of
Business Process Management system create much of the potential. While
BPMG and others spend much effort in promoting the concept (and there
are more and more success stories associated with the introduction of
BPM) the hoped for dividend is not yet what was (and could be) expected.
The use of BPM and building
Business Models and working with
the business users should be to determine if improvements could be made
to:
Process
Workflow
Organizational Structure
Operating Procedures
Business Rules
Decision Support
Project Management
before using the Process Models to generate new Information
Systems.
Standard tools encourage the illusion of progress
associated with activity; and in this case the activity of capturing
workflow. So what is wrong with workflow? It’s quite simple when you
think about it; most workflow follows the old "cow path" and most
workflow products assume that work moves from one resource to another. A
user simply enters the details, another individual approves it. But
business doesn’t work like that.
This flawed thinking is probably the main reason why
workflow (and why simple workflow based BPM) is never quite the success
most people think it should be; the resultant solutions are just the low
hanging fruit (that should have been dealt with long ago) but the
majority of processes are unsuited to this way of working.
"Paradoxically, it is the exact reason why BPM is so suited to the world
of SOA and systems to systems processes".
A quick reminder of what BPM stands for – Business Process
Management. For Business Processes a fast summarization might be:
We can manage a Process when:
| We Agree |
On what
Processes are |
| We Know |
How the Processes
interact
What each Process
delivers
How each Process produces
its deliverables
What skills are required
for each deliverable
How well each Process
performs |
| We Can |
Measure effectively
and
Manage these facts |
| We Have |
An owner
for each Process |
A rigid approach to systems processes is essential but where people
are concerned; the name of the game is flexibility. So what’s next –
what is beyond simple BPM? Process based technology that understands the
needs of people and supports the inherent "spontaneity" of the human
mind in a potential paradigm shift known as "Knowledge Intensive
Business Process" (KIBP).
This is somewhat different from Workflow or BPM as we
know it since the focus is on the work not the process. The underlying
objective of the process is still of vital importance, indeed it
provides the underlying bedrock of getting tasks completed – but these
processes are much more complex, ad-hoc, enduring and important to the
business. They are contracted processes as opposed to coordinated or
controlled processes as provided by Workflow and BPM solutions.
Although we have to deal with the unexpected this is
not about using a set of tools to deal with every (un) anticipated
business outcome or rule; we are talking about the management of
interaction that takes place between individuals and groups which cannot
be predicted but are usually encapsulated in a context, or series of
contexts, associated with a domain of interest.
Today’s BPM solutions are still very "production
centric" – most organizations don’t work this way, at least not at the
human level. The key differentiating factor of a KIBP handling
environment is that it must have the ability to run multiple procedures
against a given context of work— it is the context and subjectivity with
the appropriate available content rather than the process itself that is
used to support a work item. It is the content in context that is the
key concept of this approach not the typically modeled process of moving
of work from one resource to another.
Processes tend to "unfold" rather than rely on design
time decisions (but within the context of an overall framework).
Clearly, the activities are related and knowledge frameworks follow
typical patterns, but the process becomes the "recipe" for handling
cases of a given type.
BPM should be evolving from simple routing engines
and forms packages that are designed to manage the flow of work, and
handle controlled processes, to Process Management tools that act upon
explicit interactions and effectively coordinate known processes to
handle tacit interactions, case management and contracted processes.
If newer and newer technology is going to bring about
maturity in new-wave Knowledge Management (KM), the technology is going
to have to get primarily focused on making management processes better,
and only secondarily on making more and more spontaneous content sources
continuously reachable. In a business, the purpose of KM is to integrate
two processes, content management and work management, in order to
improve the content of work!
The
user-community for knowledge is
not homogenous, and it can be confidently separated into
roles
like managers, knowledge
workers and line workers. In a business, these roles are distinct, are
actually held to some standards of accountability, and a lot of what
passes as "process" exists mainly to avoid having these roles waste
time. These aren't per se "knowledge management" processes -- they're
work management processes. Knowledge isn't supposed to be magical; it's
supposed to be practical. How does it get that way?
The appropriate aspect of concern to investigate is
capacity development, not
process development. That is, the availability of the right knowledge in
the right circumstance is a different problem from the delivery of
at-large knowledge supplies. Determining
the "rightness" of the knowledge and of the
circumstance is not about
inherently "correct" content. Instead, it involves the use of models
that connect expertise to outcomes, not just requestors to information.
That effort needs to be systematic, but in the main
conceptually so, not technologically. The biggest practical challenge is
to shape a worker's analysis and judgment during a task, by exposing
enough of a relevant model to present, guide and validate choices -
while also capturing feedback on the effectiveness of the model's
influence on the worker and on the outcome. The problem causing the
challenge is that two unlike workers may be different primarily due to
their respective
individual
mental models - which for
starters may also differ from the common model being presented. The
payoff comes when dissimilar workers use the same model to derive
equally effective individual execution.
This shows KIBP to be generally an opportunity to
embed a consultative capability within the workflow of operations.
In that way the capacity for effective knowledge usage is enhanced for
all other aspects. KIBP's most significant difference is that it
establishes an environment in which individual workers can more readily
achieve their personal performance objectives. The key thing KIBP must
give is an improved
experience of managing their resources under pressure of corporate
priorities.
A second major principle is that leveraging knowledge
requires structured interactions between knowledge providers and users.
This is at minimum analogous to the existence of
markets
instead of merely supplies. For the
"leverage" to occur, the user must be in a position to change something
with the obtained knowledge. The value of the knowledge is logically
associated with the value of the change, so the promotion of the
knowledge is organized around that value of change.
Those principles make it apparent that KIBP, as a
business practice, should focus on two high-level outcomes:
worker position and worker leverage.
That is, if KIBP does not beneficially contribute to those two things,
it is not really adding critical value to the environment or to the
business. BPM must therefore move from its current position of simply
being a series of nodes in a workflow to that of being a place and time
where individuals can exploit their individual and corporate knowledge
to create a competitive advantage. Without this, companies drift towards
mediocrity based on process flows using common best practices associated
with efficiency rather than effectiveness.
This paper draws heavily on other papers generated by Keith
Harrison-Broninski of Role Modellers Inc. and Malcolm Ryder of
Archestra. Their publications are highly recommended.
We acknowledge their insight and
analysis which we have used to illustrate the direction we as a company
are heading in the use of Knowledge Management and its applicability to
a “better BPM”.
John Pike
