The Problem with Process

I love business process.  I hate "business process."

I love the goals and concepts and important value that comes from drilling in and understanding the planning, management, and operational measurement of business processes.  As I've said before, business process forms one of the three legs of the Enterprise Architecture "Double Iron Triangle".  (Click the image for a description of the double iron triangle).

What I hate is the term "Business Process."

The term "business process" is recursive.  A process can be made up of other processes.  As a result, a business process can be anything from a broad organizational flow (like "Order to Cash") to a very specific instance of a line-of-business flow (like "Qualify lead gathered from general business conference for license agreement sale").

For Enterprise Architecture, this is a problem.  I guess that some other folks may care too. 

In many ways, this parallels the discussion of "what level of granularity do you use when defining your services" that we see pop up in the SOA community.  The level of granularity for a service goes to the understanding, planning, design, governance, and ultimately the ability to compose that service in novel ways.

And the same thing, ironically, happens when we don't have a clear understanding of the level of granularity at which to describe a process.  If the goal is to create a "framework of process composability" that allows a process to be composed of 'common' subprocesses that have been optimized for key business objectives, then we need to know what to call these 'building blocks.' 

Clearly, the term 'business process' is too vague for that purpose.