Freigeben über

Creating a constrained definition for a measurable business process

  • Artikel

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?

Comments

  • Anonymous
    September 25, 2007
    Very nice post Nick! To be able to manage something you definitely must be able to measure it. I'd be interested in hearing your thoughts on a slightly related subject. Business processes are often subject to change. How would you handle that?

  • Anonymous
    September 25, 2007
    Hello Herbjorn, I'm not sure of your question.  Are you asking "How do you create a stable abstraction, and tie metrics to it, when the process itself changes frequently?" I would refer to a prior post of mine.  I'm working on an Enterprise Architecture Framework for Microsoft that starts with a business architecture that is NOT based on processes... but rather on business capabilities. A capability is something that a business must be able to do.  A process is how the business does it.  There can be many processes, and they will change over time, but the capability is stable.  We need to collect money from customers.  Not a lot of variation in that.  In fact, we can say that the business capability is RELATED to the business objects and business events. For any single capability, the business could have one or many processes.  It is entirely understandable if a business has two billing processes.  In fact, many businesses have a dozen or more.  Sometimes, that is not good: the result of inefficiency, silo thinking, or simply a vestige of an old merger.  Other times, it is useful and necessary.  Regardless, there is one capability, many processes. Therefore, we can compare them.  We can ask "which one of my billing processes is the best according to measure X?"  (The measure could be time, cost, resource utilization, compliance, risk avoidance, reliability, etc.) We can improve one process, merge two processes, split a process into two, etc, all because we have a stable abstraction ABOVE the process layer... an abstraction called "Business Capability." If your business would like to know more, contact Microsoft Consulting and ask about MSBA (Microsoft Services Business Architecture).  It's pretty cool.

  • Anonymous
    September 25, 2007
    Hi Nick, You got my question right. I'm somewhat familiar with MSBA, the worst thing about it is that Microsoft is unwilling to let others than Microsoft Consulting work with it. I would really like to read that prior post of yours, that is the one dealing with business capabilities and the Enterprise Architecture Framework. Could you provide a link please?

  • Anonymous
    September 26, 2007
    Hello Herbjorn, Here are some links.  Probably the best link is from my friend and partner is crime Gabriel Morgan, so his link is first. http://blogs.msdn.com/gabriel_morgan/archive/2007/07/31/traceability-from-biz-strategy-to-application.aspx http://blogs.msdn.com/nickmalik/archive/2007/08/01/putting-application-portfolio-management-into-the-picture.aspx http://blogs.msdn.com/nickmalik/archive/2007/05/04/mining-for-services-with-solution-domain-architecture.aspx Hope this helps. --- Nick

  • Anonymous
    September 26, 2007
    Tanks Nick, They are all interesting posts