The body of the enterprise can be found in the dynamics
of it's core end to end processes, the work flow. The actions
of transformation that achieve meaningful purpose. Unfortunately
many enterprises have lost sight of their core end to end processes.
They manage the body of the enterprise as pieces (functions) rather
than as a whole (core end to end processes). The work of analyzing,
designing, and sharing knowledge of core processes is the primary
work of the process design consultant (me). All the work in identifying
purpose, core processes, organization structure, measures, and
change strategies are necessary as a basis for design work flow.
It is the defining of activities and work flow interdependencies
that creates the living breathing life within the enterprise.
It is only through activities of transformation that the enterprise
provides value to customers, owners, and community.
The designing of business processes requires a multi-dimensional
collaboration of people, functions, and systems. Business process
design requires the coordination people and systems across enterprise
work flows. Each step in the work flow may have multiple behaviors,
decisions (rules), manual and systems interactions. Each step
in the work flow has a contract of interdependency with one or
more other work steps. Even simple business processes may have
thousands of possible paths from initiation to completion.
Both the analysis of existing and designing of new
enterprise core processes follows the same three iterative steps:
1)Capture (document the work flow), 2)validate (does it mechanically
work?), and 3)communicate (shared knowledge and learning). If
you can rapidly cycle through these steps, progressively widening
the review and feedback audience you will have good stable design.
The problem is not the process of analysis and design but controlling
the process as more people are involved. The catch-22 is that
the more people involved across functions the better (and more
accepted) the analysis and new design, yet the more people involved
the more conflict and time to reach consensus.
Example: A cross functional design team of process
'experts' forms, has an intense conference room learning experience
resulting in a radical new business process. They come out of
the 'war room' and senior management looks at the design and retorts
"This isn't what I asked you to do!".
Example: A cross functional design team forms but
can't come to agreement on basic design structures such as centralized
control versus decentralized control. Every design decision has
to be approved by more senior management. Design decisions made
one week are challenged the next week. Analysis paralysis and
political positioning (who to blame) follow.
Example: Five design teams form representing five
major geography's across the enterprise. Each design a piece of
the overall end to end core process. Each creates 100+ page specification.
The designs are developed but during user acceptance testing none
of the pieces fit together, even though the specifications looked
well integrated. Each blames the other for 'misinterpreting' the
specification.
If these examples don't bring you to tears, this
paper may not be of any help to you.
My experience has taught me that If I can help the
enterprise manage the design process, good designs will result,
and be implemented. In fact my warning to management is that if
we are successful they will not be able to stop the process of
change. This is the inverse of their experience of mandating changes
that get subverted with no real process improvement. Managing
the design process means that I must provide methods, tools, and
techniques to capture THE ENTERPRISES process knowledge, validate
the process mechanics (does it work), and communicate that process
knowledge to all stakeholders. This must be done rapidly (weeks
not months), in a way that is easily accessible and engaging
(not 100+ pages of narrative and diagrams), and iteratively integrates
learning (rapid feedback loops). When I can do this, good design
happens!
My primary technique for bringing the enterprise
body (core processes) to a state of health is through the use
of models. Models allow me to quickly develop process knowledge,
validate the mechanics of process interactions, and share relevant
process knowledge across the widest audience (another form of
validation and feedback learning). The models of core processes
become dynamic blueprints of the enterprise. To do this I use
a combination of traditional and object/behavior base modeling
tools.
The description of a thing is different from the
thing itself. This is the problem of complex design. The cost
of building the real thing can be very high. Errors in the design
are progressively more costly to correct later in the development
cycle. Many industries understand this and have developed sophisticated
modeling tools and techniques that go far beyond paper descriptions
and diagrams. To build a $5M building, scale models are built,
structural stresses calculated, traffic patterns simulated possibly
down to evaluation of the logic that controls the elevators, even
virtual worlds are computer created to walk through the building.
To build a $2M computer chip, logic circuits would be emulated,
speeds would be simulated, heat and interference patterns calculated.
Yet in the business world I have seen over and over changes to
business and systems processes costing in excess of $10M go from
paper diagrams directly to building the real thing. It is not
surprising that many of these efforts fail, sometimes the failure
is mechanical other times it is political. Those that succeed,
succeed at great pain and cost to the enterprise.
A typical enterprise core end to end process may
have hundreds of work flow activities, and potentially 10s of
thousands of paths from triggers to products. If that where not
complicated enough, the design of these processes requires input
form hundreds of individuals and review of thousands. Once the
design is complete it must be modified as it is implemented into
the legacy working processes and systems. Typically new cross
functional work processes require up to a year post-implementation
before they stabilize and are integrated into the existing enterprise
processes.
The design of core processes is a learning process,
not just of individuals, but of the enterprise itself.
Conventional process modeling methods are two dimensional.
Using diagrams, symbolic semantics, and structured narrative they
attempt to capture, validate, and communicate process/data design
knowledge. There are any number of these methods (IDEF, Yourdon,
Jacobson). They combine design heuristics (rules of good design)
with methods of drawing descriptions of activities, data, and
their interdependencies.
Two dimensional diagrams are useful but limited abstractions,
if you will languages, for describing something that is an alive
multi-dimensional combination of people and systems, activities,
decisions, and highly interdependent flows of information and
materials. I have found the use of traditional modeling tools
alone results in ambiguities that do not surface until implementation
phases. When the design is for the first time dynamically viewed
and tested. Design disconnects surface in both the mechanics of
the design logic and in the human interpretation of the design
specification. Resolution of these design disconnects results
in delays, organizational conflict, and great cost. Pushing traditional
methods harder does not fix the problem. Drawing a better diagram,
or adding another hundred pages to the functional/technical specification
will not reduce the breakdowns at implementation. In fact it will
compound the conflicts and finger pointing. This is why I also
use an object/behavior base modeling tool in addition to traditional
modeling representations.
The use of object/behavior models is critical. It
is the only representation that puts designers through the actual
experience of building their design and observing it run. This
build experience is the single most important thing that I can
offer my clients. People think differently when they are building
a design than when they are describing a design.
Think about your mental processes, if you where asked
to design a crane and where given a pad of paper and pencil to
work through the design. Now think about your mental processes
if you where asked to design a crane but this time where given
an erector set with all the parts available for building the real
thing. Which process would engage you best, which model would
you be excited about sharing? Now think about the same task, but
now with a group of people each representing some specialized
expertise in building cranes. Which process would be most collaborative
and facilitate rapid learning across the team? Which model would
be easiest to share with the CEO, file clerk, and information
systems designer?
The build experience (versus the describe experience)
engages the mind to action, to explore and experiment in very
rapid learning cycles. Through building
we see if and how business activities interact and then can visually
communicate the design through running animated models. Feedback
leads to progressive refinement of the design. In fact this process
can produce such rapid learning and design improvement that Stakeholder
reviews must also be accelerated as a mechanism for sharing the
learning's. The risk being that the design team goes through three
or four iterations of learning which the stakeholders are still
at step one. In effect the design team must maintain an audit
trail of learning (design refinement) as part of the Stakeholder
reviews.
Object/Behavior based tools allow the building of
working (running) prototypes of the work flow activities and their
logic. Similar to the way the logic of computer chips are emulated
prior to the high expense of fabrication. This does not replace
your diagramming, documentation, or statistical tools. What it
offers is a quick and easy way to prototype, validate, and communicate
the logic and dynamics of business process designs (current state,
goal state and transition states).
The tool that I use in my practice is Business Process
Navigator. It allows me to graphically build a working prototype
of core business processes and systems designs. Putting the designers,
developers, and business users through a shared experience of
actually building, running, observing, and measuring a working
emulation of their business and systems process design prior to
development. It does this by graphically building business and
systems objects that emulate the behaviors, decisions, and interdependencies
of the business processes. Then creates views that allow for different
viewpoints of business and systems activities. This is a powerful
tool for aligning core processes to enterprise purpose and validating
process knowledge across a broad audience.
Rather than relying on methodology semantics to capture
process knowledge, BPNavigator captures process knowledge as dynamic
objects. These objects have attached behaviors, rules, documentation,
measures, design assumptions, and any user defined knowledge that
the designers wishes to include. These objects can then become
active and interact with each other. Interactions are represented
as flow objects that capture knowledge of interprocess entities
such as electronic messaging, data, phone calls, or physical materials.
The activity and interaction of objects results in the dynamic
definition of work flows. All process knowledge is held in a knowledge
base using artificial intelligence representation techniques and
available for analysis.
By building dynamic objects of business and systems
activities, the tool requires the discipline of defining explicit
object behaviors and object interdependencies. Through activation
of the object behaviors inconsistencies in design logic causes
'breaks' in the work flow. The building of dynamic objects gives
designers a chance to feel the experience of 'building' a working
scale model. This build, run, observe, improve cycle facilitates
rapid iterations of design correction, improvement, and extension.
Each cycle is validated in a way that usually doesn't happen until
user acceptance (Does it work?). Object/behavior models can be
used to validate paper based specifications, finding process design
and logic errors buried in pages of diagrams and narratives, or
hidden in performance assumptions.
The more people involved in the design phase of business
and systems processes the more integrated and stable the implementation.
Yet, there are two fundamental problems with sharing and verifying
business process and systems designs. The first is complexity.
Business and systems processes may have hundreds of interdependent
activities (dynamic objects). The number of objects and dynamic
interactions becomes too complex to visually comprehend. The second
problem is a result of different viewpoints of the business and
systems community. Each has a different way they intuitively need
to view the business processes. Some need to see functions such
as accounting, manufacturing. Others want to see work flows, organizational
accountability, or systems architecture. Additionally many reviewers
across the enterprise can find it difficult to conceptualize the
process using paper based documentation based on semantic diagrams
and pages of text.
To address the problems of complexity and viewpoints
BPNavigator has the ability to view the underlying dynamic objects
as aggregate groups (views) defined by the process designers.
These user defined views (of which there may be many per model)
allow the simplified and intuitive representation of complex designs,
while maintaining integrity with the underlying dynamic objects
defining the process design. As an example I may want to collect
all the dynamic objects that are related to an organization (such
as Manufacturing) and represent these objects with one view icon
on the screen. All dynamic behaviors of those objects will be
displayed through that one view icon called manufacturing. This
way I can show how manufacturing interacts with collections of
activities called sales, order management, external vendors, and
customers without overwhelming the viewer with hundreds of discrete
activities. Additionally the view icon can be linked to call functions,
external programs, and other views. This creates a hypertext type
of capability allowing the viewer to navigate the process design
knowledge.
heu-ris'tic adj. serving to demonstrate or reveal
the truth.
Up until now I have been focusing on the mechanics
of capture, validate, and communicate cross-functional (end to
end) process design. Now that we have a design (new or existing)
I want to focus on the question "Given two designs, which
is better?". My goal is to share what works for me, not develop
new design paradigms or write a treatise on "good design".
My experience when confronted with a complex design problem is
that people in general don't think about good design. Their goal
is to get the process to work, then fine tune as time allows.
I believe this is a side effect of cumbersome paper based design
methods. This is why rapid iterative design using object/behavior
models is so powerful. It allows people to discard designs as
they learn better ways of working. Usually I will throw away three
to four versions before we get to a stable design that is then
improved through modification. Each version that is discard is
literally saving the enterprise hundreds of thousands of dollars.
Ultimately the client decides which design is best. As a design
facilitator it is my job to challenge and stress the design, suggesting
improvements, but the client decides how they want their business
to run.
My concepts of good design are drawn from four major
disciplines; Total Quality Management, Systems Thinking, Architecture,
my own experience. My purpose is not to write in detail for any
of these areas, but to offer in short what I find most useful
in each of these areas.
There are probably hundreds of books written in this
field. Each has insights and techniques for evaluating and improving
processes. My experience has been that TQM practitioners focus
on tactical continuous improvement. There are three areas of technique
that I use in almost every engagement; Brainstorming, Root Cause
Analysis, and Measures.
Brainstorming techniques allow me to collect and
organize process information quickly. It does this in a way that
shares knowledge among participants and evolves towards consensus.
This consensus is critical when using the information in later
stages of process design. The two areas in which I use these techniques
most frequently are for defining what activities make up a process
or work function (later used in process mapping), and the second
as a tool for collecting and organizing information on process
strengths and weaknesses (later used in cause/consequence analysis).
Root cause analysis techniques, commonly known as
fishbone analysis, are used to derive the 'Whys' and 'so whats'
of existing process problems. The strength of the technique is
to rapidly collect and structure cause effect relationships in
a way that shares knowledge among participants and evolves towards
consensus. These cause effect relationships can also be used for
building systems dynamics models to evaluate how feedback mechanisms
may be contributing to process problems.
The most useful concept I use over and over from
TQM is the concept of measures. The importance of measuring the
ability of each step to add value to the overall product. TQM
has specific techniques for development of measures, and as important,
the tracking of measures to identify trends. The goal is to identify
when a process is degrading before it impacts process efficiency
or quality. This is tremendously important when designing business
processes that must dynamically respond to unpredictable events.
Another benefit is the reinforcement of each activity to the whole.
When I have measures for each activity, have established a clear
add value relationship to the end to end core process, each individual
working knows what, why, and how they contribute. Additionally,
each activity needs to see the next steps as a customer, understanding
the customers needs and ensuring quality. When this is accomplished
individual initiative and innovation can be tapped.
Systems thinking is based on the application of fluid
dynamics analytic techniques to business processes. Instead of
pumps and storage tanks it looks at business factors such as sales,
demand and inventory levels. In general I am uncomfortable with
the application of systems thinking to the design of core end
to end processes. I don't have problems with the concepts or theory,
but with the way they are applied. Generally systems thinking
analytic models are highly subjective, but give the impression
of being scientific. How business events influence each other
is difficult to define (ie. sales increase results in lower quality)
their true relationships may approach chaos theory rather than
pumps and stores.
That said, the concepts that drive systems thinking are very powerful and useful to the process design consultant. Specifically the understanding of systems archetypes and the effects of feedback mechanisms.
The simple wisdom is that feedback delays result
in destructive process oscillations. This is particularly relevant
when process responsibility is shared (ie. end to end core processes).
In any cross functional process design I am constantly looking
for the feedback mechanisms. These mechanisms need to be built
into the process itself, not layered on top. This is key to adaptive
self correcting processes.
Systems dynamics influence diagrams are also very effective in communicating the results of root cause/consequence analysis (developed using TQM techniques).
Next to having clear purpose and vision, business
process architecture is the most powerful single factor in designing
meaningful work. If I had Aladdin's three wishes, one would be
that all CEOs would understand the powerful influence of authentic
purpose, vision, and architecture have on enterprise health.
Architecture is a fuzzy word. We think we know what
it is, but find it hard to define. I can't stand people talking
about architecture in abstract. I would rather they show me a
building and point out the architectural features. My definition
for architecture can be found along two dimensions, how the design
is used over time and reusability of the design components.
The first dimension of architecture asks the question;
is the design appropriate to anticipated use over time? An example
being the design of a house. I may need a house for a family of
six, but in the future the kids will grow up leave home, parents
will need care an possibly move in. When I design the house I
would make design tradeoffs so that the space can be adapted to
probable future uses. A business example might be an order fulfillment
process that may need to adapt to new products, distribution strategies,
or international expansion. Possibly I may have a business process
that becomes a product itself, such as securities pricing services.
The use over time dimension is the single most important factor
in determining architectural design.
The second dimension looks at how the functions within
the process are partitioned, primarily to exploit reusability.
Houses are build from standardized reusable components. This reduces
the cost of building, maintaining and adding to the structure.
Business processes tend to be customized. Even the concept of
them as engineered is weak. Large core end to end process are
rarely engineered, they tend to grow over time. This organic growth
hides the overall process, resisting change, and becoming brittle
with unpredictable side effects. Thus the job of architecting
a business process is to reverse engineer the existing process
(formal and informal), identify the common sharable processes
and reengineer the process with reusable parts (functions). This
becomes increasingly critical as a processes span business units.
For example the process of taking orders. I may have multiple
input channels (phone, electronic, mail) and many product lines.
Each product line may take and process it's own orders, or a common
order management process could be shared across business units.
This identification of architectural components is greatly influenced
by anticipated future uses. Reuse may be in the form of centralized
or distributed services, process replication (copy exactly), or
process customization (such as starting with best practices then
adding business specific functions).
Object Oriented Design methods are based on architectural
principles of design. These methods focus primarily on techniques
for the identification of common process components and the structuring
of autonomous interactive agents. OO design concepts are extremely
strong and can result in very adaptive long lived business processes.