Design Facilitation Through Object/Behavior Models - Taylor
S. Chaney
1986, Digital Equipment was re-designing it's order
management/fulfillment processes world wide. An elite team of
cross-functional specialist met twice weekly to come up with a
new design. After 18 months of intensive work, no design. War
rooms full of issues, concepts, conflicts, a lot of education
was happening but very little process design.
I had just finished a three year rotation creating the Systems Audit Function for the Corporate Audit Group and had moved to the Artificial Technology Center to design process design tools (CAD for business/systems processes). My feeling at the time was that business processes where so complex that no one could possibly understand them. Orders came in and shipments went out, but nobody really knew how.
Back to the team designing the new order fulfillment
processes. I was asked to help the design process get unstuck.
I sat and observed their 'design' process for two months. How
they interacted, how they used polite language to avoid difficult
design issues. It was like watching a dance that would never end.
After two months I challenged the group. I told them to stop talking,
and build something. I would give them the erector set to build
a working scale model of the company, their company, the way they
wanted it to run. Put up or shut up. The change in behavior was
mind blowing. They discarded their 'roles' and 'role behavior'
and became completely task oriented.
We set a target date to focus on and designed how
we wanted the business to work on that date. In three months a
solid viable design was achieved, including a scale model which
'ran' and was used to validate and role out the design world wide.
It was like taking the top off the business and watching how it
worked from various perspectives. The epiphany for me was the
shift from describing something (2 dimensional) to actually building
a running functional process (scale model). Most of our learning
is in the last third of change efforts, when we are really doing
something. Up to then we are just speculating.
Think about your mental processes, first you are
asked to design a crane and 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.
I had for many years tried to use traditional modeling
techniques for cross functional design facilitation. Most notably
IDEF, Process Diagramming, statistical simulations, and Systems
Dynamics. Although each had strengths, they only provided a descriptive
experience rather than a build experience. Additionally they were
difficult the share across enterprise functions, the learning
curve was to high, the models to complex. Traditional modeling
paradigms rely on symbolic semantics to communicate the many dimensions
of process knowledge. When using a modeling paradigm as a design
facilitation method it is important that these symbolic semantics
are intuitively understood and shared. It needs to be as easy
as walking into the enterprise and observing the process.
While involved in several large scale multi-national
systems developments I was struck by the amount of learning that
occurred in the last phases of development (integration testing,
user acceptance, and post implementation). Three years developing
and implementing Digital Equipment's systems audit function reinforced
this insight. If I could bring to the process designers the same
experience that the process implementers go though during those
later phases there could be tremendous benefits. I needed a model
that is developed in the same way that the design is implemented.
Business and systems objects are created, given behaviors, rules,
assumptions and then activated and observed through multiple view
points and levels of abstraction similar to the business functions.
The Plant Managers want to see how the plant will work and interact,
the Finance person just wants to see how the finance functions
work and interact.
This emulation of the build experience through objects
is the only representation that puts designers through the actual
experience of building their design and observing it run. Object/Behavior
based tools could 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).
While at Digital Equipment's Artificial Intelligence
Technology Center I was fortunate enough to be given the resources
to develop an object/behavior modeling tool. This tool was then
the basis of a consulting practice focusing on large scale cross
functional design facilitation. The tool is Business Process Navigator.
The Build Experience using Object/Behavior Models
In using this object/behavior modeling approach for design facilitation I have found strengths in three major areas.
Rather than relying on methodology semantics to capture process knowledge, BPNavigator was developed to capture 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.
Summary
As a design facilitator my greatest value has been to accelerate learning across the enterprise, while at the same time providing a process to resolve natural conflicts across functions. When each member of the enterprise understands, and can see, how their work contributes to the overall success of the enterprise amazing things begin to happen. The enterprise adapts rapidly to challenges and opportunities achieving a shared purpose. Object/Behavior models can be a powerful tool, creating a catalyst for cross functional learning.