Business processes form a vital asset of
any organization. You could even say they're more important than the
organization's people – because they encapsulate what the people do. But
business processes are hard to get a handle on because they're abstract.
Although we know business processes exist, and we're sure they could be
improved, isolating and describing them is pretty tough.
One response to this is to simplify the
approach and treat all business process analysis as a matter of drawing flow
charts. This has a real intuitive appeal. Organizations exist to take stuff in,
transform it in one or more ways, and then pass it back to the environment. If
you're working with physical products, then your core activities will also
generate information. But for many organizations, information is the actual
product they're dealing with anyway.
We're used to flow diagrams – in all their
different guises. They quickly suggest mechanical-type solutions: Jim has a
type-T document land on his desk, he notes what's in Section G then sends
copies to Josh and Joanne. Now, while this describes the path of a
process neatly, it doesn't tell us about the business. To understand what is
really going on here, we need to answer three questions: How do people interpret their
inputs? How do they judge them? How do they decide where to
direct them?
Jim must have a context – let's call it a
frame – which he uses to recognize and “gut” type-T documents. He can pull
what's relevant from such a document. He must also have some store of knowledge
or rule base that allows him to make judgements on what he's interpreted.
Finally, he needs to understand the responsibilities of others in the
organization if he's to send the case on to its next stage.
Capturing the logic of a flow and its nodes
allows us to build a machine that may help work get done. It can also expose
detours and rework. By annotating models of existing processes with timestamps,
we can determine where unproductive delays are occurring.
However, such models can't shed light on
the knowledge processing being done by people like Jim. And this is where the
distributed heart of the business lies.
The trend is to capture these elements of
interpretation, judgment and direction as business rules. Clearly, people are
applying rules when they perform these functions, although the rules may not
always be easy to state in formalized terms. Some rules have fuzzy edges. And
sometimes rules differ widely across similar functions.
My instinct is that targeting your analysis
on rules will have a greater value to the business than just drawing flow
diagrams. This is not to belittle process mapping, which is an important
element in bringing abstract work to life and making it amenable to managed
change. I also don't underestimate the difficulties associated with describing
rules – the history of expert systems tells us it's far from easy.
I believe rules are worth pursuing because
our experience of creating and maintaining data standards at ACORD shows how
important it is for communities to agree on what is important to them
ahead of how they represent it, store it and share it. Data modelers
never tire of asking questions like: “What do you mean by customer?” Data
standards users are delighted that they can answer, “We mean what everyone else
means,” and point at the common definition used in their industry.
Organizations surely deserve a similar
level of efficiency and certainty on the process side. We're at the stage where
people are beginning to ask: “What information, rules and measures does Jim
consider when he assesses a loan application?” But the answer ought to be
obvious. It ought to be: “He's using the standards.”
