Business processes and business rules #4
Fourth in a series exploring the relationship between business processes and business rules.
It is adapted from a paper on Business Process Architecture and the Workflow Reference Model [Lawrence (2007)1] which appeared in the 2007 BPM and Workflow Handbook published by the Workflow Management Coalition (WfMC). The full paper is available from www.makeworkmakesense.com.
Process, subprocess and task
If formulations like ‘first, take the order, then check the order, then check credit rating…’ can qualify as rules, then there can be rules within rules. There can also be rules within rules within rules – and so on. But this does not mean the logical process flow itself needs to allow indefinite hierarchies. The request-process-outcome model (see Business processes and business rules #1) provides a compelling argument for recognising just three levels.
The top level, process, is that of the model itself. A request of a particular type (eg a purchase order) starts an instance of a particular process type (eg order process). The model allows us to define a process unambiguously. It is not an arbitrary string of ‘process fragments’, or an arbitrary stretch of an ‘end-to-end delivery chain’. It is from the request to the well-formed outcome.
The second level, subprocess, is that of the steps already identified in Business processes and business rules #1 – for example in Figure 1 or Figure 2 (both repeated here for convenience):
‘Subprocess’ here means one of these steps: ‘Take order’, ‘Check order’ etc. High-level rules like ‘First, take the order; then check the order; then check the customer’s credit rating’ etc indicate status changes which are important to the business. These status changes apply to all orders, irrespective of their attributes. It is this generality which defines the subprocess level.
This is a key step in building up the meta-model. The request must qualify as a request of a particular type. Because it is of that type, a particular set of rules applies to it. That set of rules is the process. Because the rules are sequenced (according to sequencing rules!), the request will undergo changes in business status, reflecting what rules have already been applied, and what rules are yet to be applied. The subprocess level is the level applying to all requests of the particular type, regardless of any characteristics or contingencies of the individual request instance itself.
The third level, task, reflects those individual characteristics and contingencies. Different request datasets will follow different nested sets of rules and different routing because of their different attribute values. Every order will make the subprocess-level transition from status ‘awaiting Check credit rating’ to status ‘awaiting Match against stock’ (or, in Figure 2, status ‘awaiting Authorise order’). But different orders may make that transition in different ways.
Assume for example that the ‘Check credit rating’ subprocess has the following rules:
1 An order may pass Check credit rating if accompanied by a cash payment greater than or equal to the total order value.
2 An order may pass Check credit rating if the customer is not in arrears and the total order value is less than or equal to the customer’s total current unused credit.
3 Any credit increase where the total order value is greater than the customer’s total current unused credit and the customer has not sent cash with the order (but the customer is not in arrears and the order is accompanied by a bank reference justifying the credit increase) must be manually approved.
4 A customer who is in arrears and has sent in an order unaccompanied by cash must be written to requesting payment before the order can be accepted.
5 A customer who is not in arrears, but has sent in an order greater than the total current unused credit and unaccompanied by sufficient cash must provide a bank reference justifying the credit increase before the order can be accepted.
Some of these rules allow the subprocess to be passed automatically – for example if the order meets the criteria of either rule 1 or rule 2.
Because of rule 3, the subprocess will need to accommodate manual approval.
Rules 4 and 5 need the subprocess to include writing to the customer. Because of this, it will also need to accommodate recording and acting on the customer’s reply and, if the customer does not reply, some sort of follow-up.
The subprocess could therefore have a structure as in Figure 3.
‘Automatic credit check’, ‘Manual credit check’, ‘Manual record documents’ and ‘Automatic follow up’ are tasks. As the names suggest, ‘Automatic credit check’ and ‘Automatic follow up’ are automatic tasks, needing the application of business rules but not human intervention. ‘Manual credit check’ and ‘Manual record documents’ on the other hand are tasks requiring human intervention.
We said above that the task level is there because the request datasets going through the subprocess may be different, and therefore different things may need to happen to them before the objective of the subprocess is achieved.
A subprocess like ‘Check credit rating’ could start with an automatic task which processes the requests it can process, and re-routes the ones it cannot.
So ‘Automatic credit check’ applies all five rules. If the order passes either 1 or 2, it can go on to the next subprocess, ‘Match against stock’. If the order meets the criteria of rule 3, then it would route to a manual task to allow the increased credit to be approved.
To keep the example simple it will be assumed that the same manual task could allow for both approval (rule 3), and also writing to the customer (rules 4 and 5). So if the order meets the criteria of either rule 4 or rule 5, it would route to the same manual task.
In the case of just approval (rule 3), then the approved order would route back to the automatic task, which would then route it to the next subprocess. If the customer needs to be written to (rules 4 and 5), then we need two additional tasks: a manual task to act on the customer’s reply; and an automatic follow-up to loop if no reply after n days.
The details of the tasks need not concern us. The number, nature and configuration of tasks and the routing between them will be determined by the business rules for the particular subprocess, and the possible attribute values the relevant request entity could have.
With this meta-model we do not start with what people do and the order they do it in. We do not start with actors or roles, however ‘abstract’. This is where we may end up. But we start with rules.
This example also shows that although the subprocess level is important for analysis and design, as far as implementation is concerned (other than for management information and control purposes) it is technically redundant. All the work of the subprocess is contained in its tasks, and the routing between them. A process is a set of tasks strung together with routing pathways.
We will talk more about tasks in the last part of this series.
1 Chris Lawrence, Business process architecture and the Workflow Reference Model. In Layna Fischer (Ed.), BPM & Workflow handbook 2007, Future Strategies Inc, Lighthouse Point, Florida, 2007; in association with the Workflow Management Coalition.
© Chris Lawrence 2008