Formally defined, structured, and predictable business processes are beautiful. But the reality is more complex, unstructured, and unpredictable in many cases. This is why ad-hoc processes emerge, as a more flexible, unstructured, and collaboration-oriented subcategory. And later, the concept of case, and the associated case management, arises to contemplate and automate processes whose execution flow cannot be foreseen at design time. In this post, we will cover the most important elements of case management and how to automate them with Flokzu.
Ad-hoc processes.
Ad-hoc processes are those in which the path is defined at run-time instead of design-time. That is, each person who receives the process instance, studies it, and decides what is the next step, or the next person who must work on that process instance. In other words, you are not predefining (at design-time) who will be the next person.
Let’s see a concrete example. Let us imagine a process of a Ministry of Health, in which modifications to the authorized pharmacies are reviewed and authorized. A modification can go from legal aspects (statutes, responsible persons, owners), buildings (extensions, changes in distribution and circulation), doctors (medicines handled, technical responsible), etc. Then, given a new request for change, it will require review by different areas, and probably more than one, exchange information, “go and come back” several times, until a final resolution is made. A possible way to model it in a process that contemplates all the casuistry in design-time would be:
The complexity of the model lies in the fact that from each “Revision” task, you can send the process instance to any other “Revision” task, or to the “Final Approval”. The curious reader will notice that adding a new “Revision” task adds exponential complexity to the model. Detecting errors or making changes to a model of this complexity is very, very difficult.
It is a mistake to model an ad-hoc process trying to cover the complete casuistry in an explicit way. The complexity of the model generated will make it impractical and untenable in the future.
Ad-hoc processes modeling
In ad-hoc processes, and in case management in general, the ideal is not to model the complete casuistry in an explicit way (as in the previous example) but to model the behavior from the point of view of the case.
Continuing with the previous example, it would be better to include in the form the “Revision” options. For example, you could have a Combo field that allows the user to choose the next reviewer:
With this change, we could model a more generic process, indicating only that there is a specific “Area Revision” task. Which area will be reviewed? The one that the user has chosen in the previous task in the “Next Revision” combo. The process in BPMN notation would look like this:
The only remaining point to define is how to assign the users responsible for the task “Area Revision”. You can do it using dynamic assignments of tasks. That is, the assignment will be done at run time, depending on the value of the “Next Revision” field. Depending on the value of that field, for example, the list of users of each area could be brought from a Flokzu database. Or you could also assign the task through a WebService, which receives as a parameter the value of the field “Next Revision” and returns the list of assigned users.
This solution is much more practical. The model is much clearer to understand, maintain, and above all evolve in the future. For example, it is much easier to add one more “Revision Area”.
Case Management and CMMN
Everything explained above for the ad-hoc processes, is the basis of Case Management. The discipline of Case Management arises as a formal response to the management of ad-hoc processes such as the ones above. In fact, OMG developed a standard notation for case-based business processes. The name is CMMN – Case Management Modeling Notation.
CMMN has been a good addition to BPMN notation for this type of processes that require a high degree of flexibility. An important feature of CMMN is that you can serialize the model into an XML file. A compatible BPM Engine can execute this XML. In this sense, it behaves in an identical way to BPMN. It allows not only the graphic representation of the process but also its execution in a BPM Engine.
You can model the “Area Revision” key activities in CMMN this way:
Knowledge associated with cases.
Case management is closely related to organizational knowledge management. People work on the cases. Collaborate with others. Share knowledge. Work on the attached files, make comments, study the history of each case, comparing it with other similar ones, etc.
In this sense, the BPM suite should support the knowledge assets of the organization. Flokzu, for each case (process instance), besides the relevant data of the form, allows attaching files of any kind. It also allows making comments to other people to enhance collaboration. In addition, it has a powerful search engine to quickly find similar cases that facilitate taking advantage of the knowledge embedded in their resolution.
Conclusions
A case is a set of elements (information, attachments, activities), which must be analyzed by human beings. The key feature is that you can’t predefine the logic to complete each case. This implies that the flow that the case will have between people cannot be known at design time. It will depend on each case and the decisions of the people working on it.
It is possible to model processes based on cases using BPMN. But try avoiding to explicitly model all the casuistry. Instead of this, use ad-hoc routes. In this post, we presented a concrete example showing the right way to model it, making it maintainable in the long term.
It is also possible to model case-based processes using the specific CMMN notation, an OMG standard for case management.
If you think these technologies could help you or your company, schedule a meeting with one of our experts now.
