In the early part of next quarter, I am entering a research phase on a topic I have alluded to many times: techniques for Process Architecture.
One of the key problems that BPM initiatives suffer from is that, even with all the attention, we end up with processes that still have significant issues — they are too inflexible and difficult to change. They become just another version of concrete poured in and around how people work — focusing on control rather than enabling and empowering.
A phrase that I picked up (from a business architect) put it fairly succinctly:
“People tend to work hard to improve what they have, rather than what they need.”
This was then further reinforced by a process architect in government sector on an email:
“The wall I keep hitting is how to think about breaking processes into bite-size chunks that can be automated.”
The problem is that we don’t have good techniques to design (derive) the right operational process architecture from the desired business vision (business capability). Of course, there is an assumption here that there is an effective business vision, but that’s a subject for another line of research.
I am talking about the operational chunks — the pieces of the jigsaw puzzle required to deliver a given outcome. Not how the puzzle pieces are modeled (BPMN, EPC, IDEF, or any other modeling technique), but how to chop up the scope of a business capability to end up with the right operational parts.