are there any recommendations on limit on number of steps in a single process ?
We are planning a process which will have ~ 50 steps; shall we except difficulties resulting only from number of steps?
Shall we consider splitting the process ?
I am interested not only in optimization aspects but also in potential instabilities and all possible sorts of problems that we might come across.
There is no physical limit to the number of steps you may orchestrate in any particular process. I have found that a good approach is to first gather a few facts relevent to the goals and objectives of the business to understand what the best approach is in organizing the process models that need to be developed.
You might start by asking a few questions such as:
- What are the requirements for managing processes?
Will parts of a large process require rapid changes and process improvements often? How do the business administrators desire to view instance details about a process? Will individual process instances need to be controlled often, such as suspending, resubmitting, cancelling their activities?
In general with larger development teams and flexible process management requirements it is beneficial to use a modular design such that large processes can be broken into several sub-process.
It is faster to work on smaller well defined sub-processes and then orchestrate them in a parent process that meets the management and visibility requirements of the business. In terms of process development it is much easier to debug and test individual sub-processes and then include them into the parent process.
One way that the Software AG/webMethods BPMS product supports this methodology is by using a top down design and bottom up implementation approach. In this respect a business analyst or process expert can define the high level process model in the terms that make sense to the business users for tracking and management.
While here may be more than 50 steps in the process perhaps for the purpose of tracking and managing processes a parent process could be defined with far fewer steps where each step is a sub-process logically grouping related activities together.
Then each of these sub-processes can be developed, tested and deployed discretely in addition to the parent process that references them. This approach allows for changes to either the parent process or sub-processes to support rapid changes and process improvements without requiring one large process model to be managed, re-tested and re-deployed as changes to the business requirements change.
Over time as more and more modular business processes are deployed and registered in the design time library the business and IT project teams will begin to realize the power of the ability to re-use these processes to create more business processes even faster than ever before.