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.

Comments

• Anonymous
  March 25, 2008
  I've been getting the anti-BPM itch myself. I don't remember who it was, but the warning went: "Careful you don't digress into Visual Cobol now"

• Anonymous
  March 25, 2008
  Very true, basically the answer to the granularity question will determine whether BPM can deliver the promised felixbility. For now, I would have an answer to what the largest aggregation of business processes (or sub-processes) is, i.e. to what an end-to-end business process is. "A business process is initiated by a business party (customer, dealer, supplier, your firm etc.) who wants a specific interest to be satisfied or goal to be achieved via that process. The process is being 'picked up' by another party (your firm, supplier etc.). The process ends when the initiating party's goal has been achieved or when it turns out that it can't be achieved. These two points in time – ini-tiation of the process and achievement of the initiator’s goal – characterise the ends of an end-to-end business process. Hence the ends are characterised from the initiating party’s point of view." For the other end of the aggregation continuum - sub-processes and atomic activties - I only have some vague ideas, situated e.g. around conflicting sub-goals, means and ends and communication. I wonder whether organisational theory could help here a bit; I've also heard of a university institute's research project proposal around that topic.

• Anonymous
  March 25, 2008
  The comment has been removed

• Anonymous
  March 25, 2008
  Nick Good post.  Something that caught us out at Blue Prism in the early days.  We ended up introducing a tiered hierarchy which allows you to select various low level processes (tasks? actions? objects?) and piece them together into a larger process, which itself can be published as a service, or called from another process.  This pick n mix approach seems to find a good balance between flexibility and maintainability, provided attention is paid to configuration management and the orchestration layer is flexible.

• Anonymous
  March 26, 2008
  What do you think about capability modeling? Does it help here? Take a look at this article from Chip Wilson http://www.alignjournal.com/index.cfm?section=article&aid=388

• Anonymous
  March 26, 2008
  The comment has been removed

• Anonymous
  March 27, 2008
  The comment has been removed

• Anonymous
  March 27, 2008
  Hi Peter, Haven't read that one.  There's about a dozen books worth reading.  I assume you've read this one?  The reviews I've read online were either "love it" or "don't bother" kind... not a lot in the middle.   Tell me: do you think this book provides a better framework for managing the granularity of business processes? --- N

• Anonymous
  April 01, 2008
  Nick- Yes, this is a common issue with process modeling.  One of the things we have done in our process modeling area is to define different process levels (1 - 5).  Level 1 processes relate to the "Order to Cash" level of the processes.  Level 2 is more at the sub process level..  going to level 5 is describing the particular desk level workflow..   Using this terminology has been helpful in comunicating to different audiences...   -BB

• Anonymous
  April 10, 2008
  Understand that it is not the process that shapes the business by shaping what people do; it is the people that shape the process and that in turn shape the business. Agility is a human skill and will never be a software property. The more software is used to replace people and the more processes and decisions are automated the less agile businesses will become.

• Anonymous
  April 11, 2008
  Hello Freddie, I beg to differ. First off, any business that is shaped by the people is a business that has allowed its future to be hijacked.  That may be because of the personal failings of the 'leadership' but it is not typical. The business decides where it wants to go, looks at the processes to see if they support that direction, and change the processes.  We take into account the abilities of people to perform tasks, to be ready, to have the tools that they need.  But people don't "drive."  The business does. Secondly, software doesn't replace people.  It reduces mistakes.  People are more critical than ever.  Agility is not removed when you automate the routine, repeatible, arduous, or tedious processes, because you don't WANT agility there.  Heck, you don't want people there.  You want your people to be productive, happy, thoughtful, creative, intelligent, and motivated. Automating supporting processes to allow people to work in the core processes... that's the right thing to do.  Agility flourishes. -- Nick