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.”
Comments