In BPMN, an ad-hoc subprocess is one which has no sequence: the order in which their constituent tasks are performed is unknown or unspecified. The tasks therein not only have no stipulated running order, they don’t have to execute at all. Until recently, when modelling business processes, I’d use ad-hoc processes to denote business activities for which order was irrelevant or ‘unknowable’. But the use of BPM tools has thrown up a new rationale for ad-hoc processes. One which may make their use considerably more common…
Ad-Hoc Subprocesses: a Reminder
Ad-hoc subprocesses are used to present a ‘menu’ of potential activities that could be performed, at a certain place within a business process. In BPMN, they are represented as a subprocess with a tilde (˜) marker at the base; an example is shown below.
In this example, the subprocess generate report, which is embedded within a normal sequence in a parent diagram, has no internal sequence of its own. The tasks support substantiation report, generate trial balance and generate MIS report can be performed in any order within this subprocess, indeed their execution is optional. Ad-hoc subprocesses are not executable in BPMN 1.x. BPMN 2.0 allows them to be executed, providing the completion conditions are defined; it also allows a partial order to be defined among the tasks and one can specify the allowable parallelism.
When to Use Ad-hoc Subprocesses
They are commonly used when a optional list of tasks can be selected and performed in any order and there is no execution dependency between them. This is frequently the case with utility menus, when human users may choose to trigger zero or more optional tasks, from a defined list, at set times—in this example the generation of zero or more reports. It makes no sense to enforce an order of execution in this case. In other scenarios, ad-hoc subprocesses represent sets of tasks which have unknown dependencies, most often because they are dynamic and managed by a human user on a cases by case basis.
But some BPM tools have a new use for this construct.
Ad-hoc Subprocesses in BPM Tools
For BPM tools that support them as part of their BPMN modelling environment, another use has emerged for ad-hoc subprocesses: the definition of a set of tasks for which the execution order is not yet known. In other words: ad-hoc subprocesses represent sets of tasks for which the execution sequence and dependencies are not fully understood at the time of definition, but it is expected that this will be discovered later.
Indeed, these same BPM tools (e.g., IBM BPM) allow the use of ad-hoc subprocesses, defined in early versions of a business process, to be monitored, so that the real sequences and execution dependencies can be captured by the tool from actual usage scenarios. This knowledge can then enrich later versions of the business process which can be more proscriptive about sequencing, thus making the process safer and more robust. This means that, in early releases of a business process, there are two classes of ad-hoc subprocesses: those that are fundamental (in which sequential constraints are not pertinent or desirable and will never be specified) and those that are ‘nascent’ (in which the absence of sequencing is temporary, a function of the current lack of understanding of the process by the SMEs building the model).
As a result, ad-hoc subprocesses seem to allow an earlier time to market for processes with poorly understood details.
Conclusion
This use of BPM to both orchestrate a defined business process and capture some details of it ‘from the field’ is part of the way in which they support agile delivery. It makes it possible to deliver a partial process definition which the BPM system itself will help to refine. In addition, the resulting process definition, enriched as it is from real usage cases, is more likely to be satisfactory to its human users.
Recent Comments