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.
11 thoughts on “The Problem with Process”
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"
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.
In the past I’ve used the term "Process Step". Any Business Process may be composed of any number of Steps, and a Step itself may also be composed of Steps and Activities. Activities define the inidivual operations that are actually undertaken.
The term "Step" is suggestive of being part of a journey, and of making progress towards a goal.
In my view a Business Process should define the high level processes an organisation uses to achieve its business goals. These are the top-most level at which a process can be defined and has the lowest level of detail. They must be at the level any senior executive will understand with minimal operational detail and can be used to simply define what the organisation does. Anything at a lower level of granularity is just a step in the journey towards the business goal.
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.
What do you think about capability modeling? Does it help here?
Take a look at this article from Chip Wilson
We’ve been using capability modeling for about three years. It is part of our EA framework that allows the mapping of strategy to program spend to insure alignment. Regardless of what some say, using capability, by itself, reduces JaBoWS but does not resolve it, because the capabilities are not created using a guiding principle that aligns them with the information stored in systems. Capabilities are aligned with business functions, which are necessarily orthogonal to business systems. Where capability modeling helps is that it reduces the number of business functions, and therefore offers a point of unification of BUSINESS PROCESS ACTIVITIES. If you unify the activities, you get a benefit in the SOA, but it is not uniform. Some areas get a stronger benefit than others.
If you are trying to eradicate Malaria, and you kill all the mosquitoes using DDT, then you eradicate Maliaria. You also kill a lot of birds. It’s a side effect. Similarly, you get a reduction in JaBoWS as a side effect of capability modeling, but it is not a uniform, or desired, side effect.
Have you looked at the Business Process Management Framework by Roger T Burlton – a process/methodology for doing BPM – see http://www.processrenewal.com/
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?
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…
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.
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.