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.
Having just finished the dynamic case management Forrester Wave™ — it will probably appear in mid-January — I was struck by the variation in the approaches between the vendors; especially how they represent the organization, and the variety of wrinkles associated with work assignment. This was not so much related to an individual case management vendor, but it became apparent when you looked across the products. And that got me thinking and discussing with colleagues, customers, and vendors around the challenges of realistically supporting the organization as it looks toward BPM generally. Of course, there are many different issues, but the one I want to focus on here is around organizational structures, roles, skills, and responsibilities.
The central issue I want to highlight is one that many folks just do not see coming in their BPMS and dynamic case management implementations. Very often, there is only a loose concept of “role” within an organization. When the word “role” is used, it is usually equated to an existing job title (part of the organization structure), rather than responsibility (at least initially). It is further complicated by the fact that within a given job title, there are usually wide variations in the skills and expertise levels of those who work in that area. And while this is not a problem where people manually coordinate their work, when it comes to automating work routing (to the most appropriate person to deal with a given work item or case), there are often major complications.