Today I came across a problem of modelling good business processes. It is a problem I often run into by myself and also observed sometimes by my customers. It is about the generalisation of business processes and how to avoid this pattern.
The Core Idea of BPM Systems
One central idea of a BPMN engine is to abstract common business cases by building a system that is able to control any kind of business process independent of a specific domain. Only the concrete model represents the reality of our business world. This is the big difference to domain specific business applications like a stock management system or an accounting system. A BPMN engine does not know about a specific business domain, its processing rules or its data schema. Alone the (BPMN) Model defines the nature of the business process.
So if you have different domain-specific business processes you need to design different models. Each model represents one business process. This seems to be obvious, but there’s a thin line between specific process models and the temptation to create generic process models.
Specific vs Generic
The most obvious case occurs when you try to map a ToDo workflow to a BPMN engine. The ToDo can be open or completed. Then you define two input fields, one to describe the task, and one to set a category (‘create invoice’, ‘schedule meeting’, ‘send offer’…).
And now we’ve created exactly the problem: we have a generalized process model running inside a generic process engine!
The problem is that the BPMN engine treats all tasks in the same way, regardless of whether you’ve marked them as ‘Invoice’, ‘Meeting’, or ‘Offer’. All are still ToDos which can only be ‘open’ or ‘completed’. In the worst case, you now need to extend your data schema so that you can select all invoices or payments by the ‘category’ field – and only because your model was too generic and not specific enough.
Of course, this is an exaggerated case of bad modeling. But this pattern of over-generalization also occurs in many domain-specific business processes.
Imagine you have to create a model for outgoing invoices, with a distinction between domestic and international invoices. Just like in the ToDo example, you could treat this distinction as a category within one generic model – or you could create two specific models that share large similarities but remain distinct.
Conclusion
The difference is huge, because as soon as you define different models, you gain the full leverage that BPMN engines offer. They can manage processes based on the model used and its current state – with no need for additional categories, which would only limit the system.
So my recommendation is simple: always make sure that domain-specific requirements are represented by domain-specific models.