We recently had a great discussion about determining the size of a process. You can see it in the BPM Group on Linkedin for the full effect, but I try to summarize the varying views from that discussion here.
So how do we determine the right size of a process? It’s a great question since a huge processes would be a terrible chore to maintain. Spaghetti comes to mind. Do software design standards help this area of the business? High cohesion, low coupling, modularity? Is it possible or helpful to have many smaller processes? Here are some of the answers proposed. They have been edited and shortened for this blog post.
Amit Mishra
- Use a maximum of 25 nodes per process and decompose into sub-processes when it gets larger.
Martin Axt
- Agrees with my theory (don’t determine the size), but you do need strong documentation.
Jose Camacho
- Internal/External customers define the process beginning and result.
- If necessary, it can be decomposed to smaller parts while preserving full E2E logic.
- Improving activities outside these processes doesn’t allow measurement of ROI.
Pedro Sobreiro
- Based on Alec Sharp’s research, suggests macro processes be decomposed into five to seven sub-processes.
- Use common sense combined with expertise.
- If process is modeled by management, it should be kept simple.
- If modeled by IT staff, it should be decomposed and usable by them.
Paul Gothard
- Using abstraction/aggregation you can model the full end to end model without being overly complex.
- Using repository based tools helps.
Richard Cunard
- Use a Process Purpose Diagram (PPD) – This method defines exactly what the purpose of the end-to-end process is. It typically is made up of one or two sentences and it considers all facets of a process.
- Purpose-Oriented Function Tree (PFT) – Once the purpose has been defined for the process, using a purpose-oriented function decomposition approach, we next create the supporting function tree.
- The PFT model adds value along the way: It is an elegant way to ensure only value-adding steps are included.
Subbu Lyr
- When you design a process, it is recommended that each level is not more than 4 -6 parts each; thereby making a process manageable or in this case “appropriately short”.
- Need to master process design.
- Getting from abstraction to details:
- Enterprise Process
- Sub – Process
- Activities
- Tasks
- Transactions
Pedro Sobreiro
- Tregear proposes: alignment happens when strategy defines processes.
- Process changes are initiated by projects.
- Projects improve processes and processes execute strategy.
As you can see there are clearly a wide range of opinions on the matter. That means we have a good discussion on our hands!
I proposed that process size is irrelevant if you take a narrative and agile view, should your software allows it. This view minimizes the role of models. That’s important to note. We learn from systems theory that models are always fictional. But what did you expect from me? I seem to take the emergent view of things whenever I can.
If you have an important view to contribute please do so.
Follow
