Creating a constrained definition for a measurable business process

Ask ten business people about "the billing process" in your company.  Get specific.  Diagram it out.  You will get eleven answers. 

I had the opportunity today to 'approve' (e.g. "not veto") a very generic definition of 'business process.'  It was something to the order of 'a series of tasks in support of a business goal.'  It was followed by examples, including something along the lines of 'invoice the customer.'

Very generic.  I'm OK with it because it is not really meaningful.  In other words, it is so far from useful that it really doesn't matter.  There's no way to wordsmith something that generic and end up with something useful.

A generic definition of 'business process' is not actionable.  You cannot judge the quality of a business process by matching it up to such a generic definition.  You cannot tell if one series of tasks is not a process, while another series of tasks is a process, because the quality bar is so low. 

Another problem is that a process can contain a process.  ad infinitum.  There is no stated limit.  In fact, two different processes may share the same subprocess.  It's not just an infinite hierarchy... it's an infinite Directed Acyclic Graph!  Creating useful metrics can range from difficult to impossible.  In practice, I'd be thrilled with 'difficult.'

If I didn't care about business process, I wouldn't care that the definition is generic and vague... but I'm a SOA guy... and SOA is meaningless unless you understand and manage the business processes.  Reality check: if you aren't building your SOA to support your actual business processes, you should probably just start over. 

So business process matters, and I have a generic, recursive, unactionable definition.  What's an architect to do?

Come up with a new definition, of course. 

Only I can't say that I'm defining a 'business process.'  I don't want to be watered down with that term.  No, I'm not going to replace junk with junk.  I'm defining something more useful, more constrained, more measurable than a random selection of tasks where I can say that the last task defines a business goal...

So how do I design a defiinition?  The same way I design anything else... I look at the requirements first.

What do I want to do with these 'better processes' that I am defining?

Well, I want to optimize them.  I want the business to have three where it needs three, and one where it needs one.  I want to measure them, so that I can improve them.  I want to attribute them, and then compare processes on the basis of the attributes. 

So, how will I do all those things?  I'm in a large enterprise.  We have tens of thousands of processes.  How do I define the concept so that 500 analysts can collect processes, in their own business areas, and yet, when we are done, I can compare them to one another without laughing?

First off, we need some kind of stable context... something that provides common language across all business streams.  Otherwise, measurements are meaningful for improvement, but not for comparison.  Let's use a set of business objects: things that we use to manage and track the business.  Invoice.  Sale.  Customer.  Order.  Product.  Now we can talk about all processes that impact a particular object, and we can find those processes in our database by searching for the object that is created or manipulated in the process.

Then, we need a consistent way to start and end the processes.  How about we create a list of well-defined events?  An event is a transition point where a business document changes state in a meaningful and consistent way.  Therefore, when a shipment goes out, we create the invoice from the purchase order.  The act of creation is an event.  When the customer makes the final payment on the invoice and we close it, that is another event. 

If objects are the things we manipulate, and the events are points in time, then the processes in an organization are the things that we DO with those objects either to get to an event or as the result of an event.

Oh, look, we almost have a useful definition for business process!  But we aren't done yet.

One more thing I don't like about the generic definition... the notion of a business goal.  The way that is interpreted, a business goal can be almost anything. It doesn't have to be measurable or meaningful.  Let's refine that. 

I would state that if we are to meet our objective of optimizing and simplifying our process portfolio, we need our process to be measurable.  I would say that we don't want to support 'any' business goal.  We want to say that a process is completely defined if it delivers a capability that the business needs. 

So now we have the bits for a definition.  Almost everything... except a name for our new concept.

What we have defined is still a subtype of "business process."  However, it is more constrained.  We have made it measurable.  We have given it common starting and ending places.  We have stated that it supports capabilities, not mere goals.  How about we call it a 'normalized business process?'  

Let's put it all together.

A 'normalized business process' is a measurable and ordered series of business activities that begin and end with well defined business events, and which is designed to deliver all or part of a business capability.

Now, that is a definition that only a geek can love.

On the other hand, it is useful.  We can look at a 'business process' and know if it meets the criteria for calling it 'normalized.'   We can make statements to our analysts like: 'the quality bar for business process entry into our BPM solution is that it must be normalized.'

Who knows... we might even be able to drag a few reusable, composable, well partitioned services out of these well-defined things.  And wouldn't that be refreshing?