Business Process Management (BPM) via DEMO (1)

This is a rewrite of a previous blog inspired in part by [1]. To recap, personnel management division in service organisations perform many transactions (in the sense of DEMO) and execute collaborative processes to manage the information necessary to maintain employee and employer relationships in the organisation. Knowing these transactions and their interactions provides better automation and optimisation opportunities. Although, many of these transactions are routine, those that comprise resource management are the most important, as they directly effect the organisations revenue generation ability. We have chosen to partition the recruitment process into four transactions that are independent and promised and executed by different roles. The participant playing the role of the interviewer may differ from each resource request, they are requested to participate based on their technical knowledge and availability. The pattern depicted by the recruitment process is the "serial double basis PR-AE" as mentioned in [1]. We have taken some liberties with the original pattern to more suit our purpose of analysing a departmental process with a view to automation.

We can enumerate the transactions as follows:

• T01 — Managing the resource requests
• T03 — Search and resourcing of the required resources
• T04 — Evaluating the resources
• T02 — Finalizing and getting the resources on board

Figure 2: root process —

Managing the resource request

In this transaction the two actor roles are the "client" and the "recruitment manager", while the "recruitment manager" role is part of the serviceorganisation and hence of interest to us, we are not particularly concerned which role performs the request function for the client. This is a root process, in the sense of [1], which starts the business process for the handling of the resource request within the PMD. Although, the “root process” looks correct it is incomplete as the closing activity of the “recruitment manager” step, after the clients acceptance (“ac”) step, is missing.

Figure 3: modifies root process —

The problem is that the activity is part of the original promise “pm”, but it can only be performed after the acceptance. In business terms, the organisation will not hire the resource until there is a confirmation to hire.The best way to modify the "root process" as depicted above is shown in the figure on the left, it keeps the integrity of the whole transaction together. But, to differentiate the original client request ("rq") from that which is fired after the client acceptance ("ac"), we have had to rename the transaction as "T02". This may not be entirely correct in the purist DEMO sense, but it does allow us to understand the final stage of the "root process" better. Since it can be argued that the T02 "request" is indeed a request from the client to have the resource taken on-board.

The action model for this transaction is made up of the following action rules,

Figure 4: action model —

The action rules in ‘Figure 4’ are only illustrative, if the request is for a resource with "mainframe" skills then the request is declined. The actual action rules when produced for all transactions can get quite dauting.

Figure 5: attempted BPM —

The BPMN diagram Figure 5 (courtesy of ARIS Express), is the BPMN representation of the demo analysis above. It must be remembered that the BPMN design is very subjective and there are many ways of implementing. Our attempt is to high lighht the case management aspects and the fact that the knowledge worker (specifically the recruitment manager) may execute the tasks in any order and as many times as necessary to complete the resource request. For this same reason we have chosen to portray the sub-processes as "ad-hoc sub-processes". We also wanted to monitor each transaction as depicted in the DEMO model, and hence the sub-processes design, and also chose the communication between the sub-processes to be non-interrupting message event.

The DEMO diagram in Figure 1, suggests that the "sourcing" as an collaboration with an external partner, where as in the BPMN (Figure 5) it is not so obvious. In affect we have not created the external partner collaboration, the activity is done as an task by the "recruitment manager", this in fact can become a bottleneck in most outsourcing organisation. There is much to commend DEMO as a tool for process analysis and a pre-cursor to BPM implementation.

[1] P. Van der Horst