Discussing what is an adaptive process and what not by example
Blog: Frank Michael Kraft's Blog
The German journal “Computerwoche” published an article about Adaptive Case Management, authored by the “Masons of SOA”. (Maier, et al., 2012)
This in my eyes is an encouraging sign that the ideas and concepts of Adaptive Case Management are being picked up and replicated.
There is an introduction about Taylorism in office work and their effects on BPM, especially the unfitness of this philosophy for the knowledge worker. They argue as we do in (Swenson, et al., 2010) that this is the reason, why BPM is not as pervasive as initially expected by experts. My thoughts on Taylorism have been published here.
BPM is currently limited to repetitive and well-structured processes and they say only within organization units (as opposed to cross many organization units). Processes like on-boarding of new employees as they write, with many approvals on many levels of management.
They propose to define BPM as consisting of normative BPM (nBPM) and adaptive BPM (aBPM) from now on, where aBPM covers all the new requirements and capabilities that come with Adaptive Case Management. I am happy that this is perfectly in line of what I proposed here , where I already proposed the Term ABPM. It makes sense to define the “rest” of BPM with another term and I like the term normative BPM, I can agree to this. Both are tools in the toolbox that are used for the right purpose – we are in perfect agreement on this.
Later in the article, the authors show a model of a process that is an example for the limitations of classical (normative) process modeling.
Figure 1 Insurance Claim Process from (Maier, et al., 2012) – translated to english
I want to elaborate a little bit in this post on what are exactly the limitations.
The first gateway is an inclusive gateway, meaning one of both paths is chosen, depending on what is necessary. This is certainly something a knowledge worker wants. But I must remember, that a BPMN model has a clearly defined execution semantics, meaning that if this model is loaded into any workflow engine, then the workflow engine executes the process according to this semantics – which is a token flow semantics. In other words, only those tasks appear on the screen, which are activated by the token. Based on that execution semantics, it is possible to simulate such a behavior. So let us do this. For this I am using the new BPMN token flow simulation tool from Prof. Allweyer. For that I must tweak the model a little bit, because the tool currently does not support ad-hoc tasks. I just remove the ad-hoc attribute from the two expanded sub-processes “Customer Service” and “Claims Processing”. The execution semantics is still the same.
A token is marked as a star in the model.
Figure 2 Token before Inclusive Gateway
The first problem we see in Figure 2 and Figure 3. The data-based gateway (and the inclusive gateway is a data-based gateway) is defined in a way, that the decision must be done as soon as the token reaches the gateway. That means, before the decision the token is before the gateway as in Figure 2, and after the decision the token is after the gateway as in Figure 3.
Also the semantics is that the decision must be made based on data from the process. Where is this data coming from? What is the role of the knowledge worker here? But let this be only a side remark.
Figure 3 Token after decision of Inclusive Gateway
Suffice it to say that after the decision has been made, it cannot be revised. If the token is after the gateway, then it is not possible to activate the other branch, like “Customer Service”. Yes, because it is an inclusive gateway, the decision could have been to send the token into both paths. But inclusive also allows for only one path. So if the decision is done, it is irrevocable. And the decision is already irrevocable, before even the first succeeding activity has been started. This is not how knowledge workers work.
I call this pattern of knowledge work “The XOR lie” in (Kraft, 2012). Ok – if I consider the inclusive gateway I should name it “The gateway lie” – but the argument is the same. Adaptive Case Management is not bound to the gateway lie. It is more flexible. In (Kraft, 2012) I explain this in more detail. My point here is only to explain the problem.
Figure 4 Token in Ad-Hoc Sub-Process “Claims Processing”
There is another problem with the model in the ad-hoc part. As we see in Figure 4 all tasks of the ad-hoc sub-process are activated, as soon as the token reaches the ad-hoc sub-process “Claims Processing”. But as soon as the token leaves “Claims Processing” – as in Figure 5, none of the tasks is active. What does that mean? That means, that the tasks of “Claims Processing” can be executed as long as the token is there. The knowledge worker can decide which task he executes, and he can decide the sequence in which the tasks are executed. But as soon as the token leaves “Claims Processing” it is over. Finishing “Claims Processing” is irrevocable. What is there is delayed Case based information collected, which does influence the whole case? It is not possible in this process to reopen the Claims Processing again. That is because the decision to finish it is irrevocable. That is not how Knowledge Workers work.
Figure 5 Token after “Claims Processing”
Also there is another caveat in this type of model. Only those activities can be processed in the process (i.e. tracked in the workflow system) that have been modeled in advance. For example it is not possible in this model to include something like “get mangers advice about case”. Yes – the knowledge worker can always ask his manager – even without the workflow system. But the task cannot be tracked. This is how knowledge work is done today – just do it without workflow system. Send and Email, phone, meet. Whatever. But what we want is, that the new task is also tracked, even if it was not preplanned. The knowledge worker wants to collaborate with is manager over this task, referencing all case information in the Adaptive Case Management System (that is available already) plus adding some special information for the task as attachment to the task, forward the link to the task, search it, estimate how long it takes, see if the deadline can still be met, see a statistics in which can be seen how many cases of a certain type needed manager`s advice and so on – in one word: Manage the task. That is why it is called Adaptive Case Management.
So with this model – and by this with any workflow engine that uses this model – it is not possible to manage tasks, which have not been modeled before. That is not how Knowledge Workers work.
If this model was to be transformed to an adaptive model, then It would be necessary to model also data objects and their state, which is absolutely vital in every adaptive process. The model does not have a data object modeled (“Claim”) not their state ([Incoming], [Evaluated], [Not Relevant], [Assinged], [Released], [Paid], [Rejected], [Closed]). Adaptive Processes are not merely tasks. Adaptive Processes are the wedding between task and data – between business processes and business objects. Furthermore as we can see this model is task-oriented instead of goal-oriented.
So this model demonstrates very good the current limitations of classical (normative) modeling if we try to capture adaptive processes with classical means. Thereby fundamental principles of adaptive processes are violated:
- Goal-Oriented instead of task-oriented.
- Not fully prescribed – individual processes.
- Changes in the running process
- A clear status of the business object
It is important to understand this, because then it becomes clear why Adaptive Case Management is something really new – something revolutionary. Not just using current technology in a slightly different way.
The authors and me are in perfect agreement about these facts. That is why they made this model as an exampel of the limitations of normative process modeling with regards to adaptive processes.
Of course it is a pity, that there is currently not yet an internationally standardized graphical notation for Adaptive Case Management models, as with BPMN. Not yet. I must emphasize that there is still some work to do, before this can be achieved. But it is on the way.
The article closes with stating, that currently there is no standard software supporting Adaptive Case Management. While I agree that it is a young discipline, and software is currently being developmed by different companies, there are some companies, that offer ACM. IBM, Isis Papyrus and last but not least of course AdaPro offers standard software for Adaptive Case Management – and these are not all. Some of them are in pilot mode, others in productive.
So we can see that now the train of Adaptive Case Management and Adaptive Processes in general is picking up speed, the requirement for managing unstructured processes is now recognized and confirmed, and the discussion how this can be achieved reaches the BPM and SOA communities around the globe as well as in Germany. I am happy to see that and I am sure, that by honestly analyzing the problems of current technology and proposing better solutions this will revolutionize the realm of process management.
Kraft, F. M. (2012). Adaptive Case Management – On-Demand Training. Retrieved from AdaPro: http://www.adapro.eu/site/seminar/sem-acm-on-demand/
Maier, B., Normann, H., Scheithauer, G., Schmiedel, D., Kress, J., Utschig-Utschig, C., et al. (2012, 03). BPM: Annäherung statt normativer Prozesse. Computerwoche, pp. 32-34.
Swenson, K. D., Jacob P. Ukelson, J. T., Khoyi, D., Kraft, F. M., McCauley, D., Palmer, N., et al. (2010). Mastering the Unpredictable. Tampa, FL, USA: Meghan-Kiffer Press.