We introduce in this blog series the concept of Case Management Process Modeling (CMPM) - An emerging concept complementary to existing Business Process Management (BPM) concepts. In this second blog entry, we explain modeling aspects of a case that could be interesting for the currently developed standard for CMPM by the Object Management Group (OMG). This blog entry is relevant for enterprise architects, product managers and business analysts.
Goals of Case Management – Recap
I wrote in a Case Management Process Modeling (CMPM) – An Introduction that case management is focusing on dynamic evolving processes for managing critical business assets. It is thus fundamentally different from operational business processes modeled in the business process modeling notation (BPMN) and managed by workflow systems. Case management is complementary to business processes and requires new models as well as systems to support it. Examples for cases are insurance cases, healthcare cases or cases related to public services (e.g. crime investigations). Clearly, all those cases are of highly collaborative nature.
Stakeholders of Case Management
We illustrate in the following figure some typical stakeholders involved in case management.
These stakeholders seem to be similar to the ones involved in BPM. However, in case management, they need to collaborate much more to align their goals according to the evolving dynamic process. We distinguish the following roles:
- Case Designer: The case designer is the creative business analyst describing and modifying cases according to business needs. This role allows the case workers to work freely on a case as they think it is the best way - given only few constraints (e.g. regulations). He has to align the case with enterprise-business rules defined by the global business rule designer.
- Case Worker: The case worker works on the case and manages the evolution of processes related to the case based on his/her experience. He reports to the case owner. Several case workers can work on the same case and thus they need to collaborate with each other mediated via the case. This type of collaboration offers much more freedom than enforced collaboration by a business process management system.
- Case Owner: The case owner manages the relationships between different types of cases and the people related to these cases. He ensures that cases generate the maximum business value taking into account risks and opportunities.
- Global Business Rule Designer: The global business rules designer describes rules according to enterprise wide goals and regulations. This role has a more global and strategic perspective independent of specific cases. He works together with the case designers and case owner to continuous align global and local perspectives as well as perspectives of external stakeholders (e.g. shareholders or governmental organizations).
After having understood the stakeholder of case management, we describe in the following paragraph some guidelines for modeling cases, so that the different stakeholders can align their efforts more effectively and efficiently.
Modeling Guidelines
Every effort to map enterprise operations requires a consistent way to model them. This ensures good information quality as well as process quality. The Guidelines of Business Process Modeling (GOM) support this from a business perspective [4]. There are six fundamental guidelines:
- Economic Efficiency: This guideline affects all the other guidelines. Case management should only be used where appropriate and where it provides adequate cost-benefit ratio. Many processes in companies are dynamic and evolve in an unstructured manner, but not every one of them should be management by a case management system.
- Correctness: This guideline refers to syntactical and semantic correctness. A model should be syntactical correct according to the case management modeling language (see also the Case Management Process Modeling (CMPM) – An Introduction). Semantical correctness means that the static and dynamic aspects of the real world are correctly articulated in the case by the case designer and case worker. Case management can help here to some extent, because it allows evolving processes to anticipate and react to changes in the environment.
- Relevance: Cases should not cover every aspect of a case, but only relevant aspects. An element in a case is irrelevant if it is not utilized by the case worker. Keep in mind that cases contain evolving processes for managing business assets, so new elements may become relevant and old elements may become irrelevant over time.
- Clarity: A case needs to be understood not only by the case designer, but also by case workers. It should be clear to every relevant stakeholder what has been done in a case, what is currently going on and what can be the next steps. We will see later that this is not always given, when considering current technology.
- Comparability: This means a company should use the same guidelines for all cases across the enterprise. Otherwise we cannot compare, for instance, the execution of different cases from a cost-benefit perspective.
- Systematic Design: The different perspectives on a case (e.g. business assets, data, rules, activities or people) should be aligned with each other not only in the case management system, but also in any other system integrated with case management (e.g. records management or enterprise resource planning)
It is crucial for case management to establish these guidelines throughout the organization, because the process can be influenced by different stakeholders and this should not lead to inconsistencies or ambiguities. Some of these guidelines can be supported by adequate case management information system support.
Of course, these guidelines need to be operationalized differently depending on your organization and what you want to achieve with case management. Keeping this in mind, we can now focus on the modeling elements in a case.
What could be Modeled in a Case?
We identified several modeling elements from our experience as well as research literature (e.g. [3,5-6]). A case has a lifecycle and is a container for the following elements:
- Business assets and their lifecycle
- Activities and their lifecycle
- Case Rules
- Data
- People
We explain these elements now in more detail.
Case
A case is a container for any other element relevant to it. It has a lifecycle describing the different states of a case. Of course, a case can only be in one of the states of the lifecycle. The states may also refer to important milestones of a case. This is similar to project management approaches.
We provide in the following figure an example for a case and its lifecycle. It is about an insurance case. It can be in the state “Initial” when it has been created. Further information about the person that needs to be insured as well as basic insurance contracts need to be added to the case, so it can change into the state “Active”. The state “Active” means that there are no problems with the insurance case and that for example further insurance contracts can be added. It may change to a state “Incomplete” if important events in the life of the insured person happen, such as marriage or illness, and important additional insurances are missing. It may also be in the state “Suspended” when the person moves for some time to another country and payments for the insurances in the case are on-hold for this time. Finally, the case may change to state “Retirement”, e.g. when the person to be insured has died or left the insurance company.
Of course, other cases may have different lifecycles depending on the needs of the organization.
We have found out based on our experience that case workers need to describe also more information about the current state of the case. For example, it seems to be very important for different case workers to provide more information why a case is in a certain state, such as suspended, and what is needed to move it to another state. An insurance case might be suspended, because a case worker waits for information. Other case workers checking the case should know that this information is still missing so that they do not resume the case without it.
A case management system can provide more sophisticated means to do this by utilizing the available elements, such as rules or data.
Business assets
Business assets are of key importance for any company and generate value. It is thus important that business assets of the same category are treated the same to ensure consistent value generation. An example for a business asset in our case is a life insurance contract. We illustrate the business asset “life insurance contract” and its lifecycle in the figure below.
Similar to a case, a business asset can be in different states. For example, an insurance contract it is in state “Initial” when the business asset has been created. It is in state “Active” if all payments for it have been received, the customer did not die and is not retired. It is paid out when the customer is retired, but it is not paid out if payments are missing or the customer died. You can imagine that a lot of business processes are involved in managing a life insurance contract and thus having a business asset as a first class citizen exposing the same consistent view to all processes as well as stakeholders is beneficial to avoid inconsistencies (e.g. the life insurance contract is paid out when the customer died, but still payments are missing).
Several synonyms exist for business assets, such as business artifacts or business objects.
At the moment, we are able to describe business assets. However, how can we control how their state is changed and how do we define the relations to other business assets? For example, a life insurance contract may be related to a disability insurance contract.
There are two solutions: State changes are governed by activities and relations to other business assets can be described using rules.
Activities
Activities describe typical actions that can be performed in a case. There are different types of activities. For example, activities may refer to actions for opening a document and working on it. Other activities may require human action. Further activities may refer to completely automated business processes expressed in the business process modeling notation (BPMN).
Nevertheless, we expect that case management requires mostly human-based activities. Case data can be processed by activities. Activities may also have as an outcome a state change of a case or business asset. They may also have as a prerequisite a specific state of a case or a business asset. For example, new contracts can be added to an insurance case only if it is in state “Initial” or “Active”. Finally, activities may be constrained by rules (see below). For instance, if the age of a customer is above 80 then certain insurance contracts cannot be added to a case.
Similarly to cases and business assets, different types of activities may have different lifecycles. For example, let us assume an activity for paying out a life insurance. It may be required that several people (see below) confirm that the life insurance can be paid out to the customer. An activity with such a lifecycle is illustrated in the following figure:
Other activities may have a simpler lifecycle. For instance, an activity for opening a document may only have the states “Initial”, “Execute” and “Finish”.
Other synonyms for activities are actions or transactions. The activity concepts presented here have been part of our research [3].
Furthermore, we can also leverage novel standards, such as Web Intents or Web Activities to rapidly deploy new enterprise or business network wide capabilities.
Case Rules
Case rules constrain the transition from one state of a business asset, activity or case to another state. This means they define preconditions and post-conditions when changing the state of one of these elements. For example, a payment activity may only be initiated when the customer has paid 5 years into the life insurance.
They are specific to a case, whereby enterprise-wide business rules may apply to all cases. Rules allow the user to specify freely in which order activities are performed given only some restrictions (e.g. regulatory ones). Furthermore, rules can be used to specify the relations between different business assets (e.g. a life insurance contract is bundled with a disability insurance contract).
We distinguish between two types of rules:
- Event-Based Rules that are described using an Event (E) a Condition (C) and an Action (A) – ECA format.
- Example:
- Event: Customer dies
- Condition: Payment of insurance rates over at least 5 years
- Action: Payment
- Example:
- Duration-Based Rules (see also [3]) :
- Example:
- As long as the life insurance is in state “Active” or “Payments missing”, insurance rates can be paid by the customer
- As long as the customer is “married”, subsidiaries can be requested from the government
- Example:
Both types are equally important. Event-based rules are used to react on a given event (e.g. customer dies). However, dynamic processes cannot only be about reacting to events. There is also a need to plan the evolution of a dynamic process to some extent in advance. This can be done using duration-based rules.
It is possible to use one out of the many different rule formalisms and mechanisms to verify correctness of a given set of rules, but intelligent case management systems combine different ruleformalisms to do this. This enhances the performance and thus speeds up complex change operations for rules. This is important, because we have argued before that the process evolves with the case and thus is subject to continuous change.
One main challenge here is how rules should visualized to the case workers, so that they always know what has been done, what is currently going on and what can be done next.
Data
We have explained before that case management is particularly suitable for dynamically evolving processes. This implies that not everything can be modeled in a structured manner as a business asset. There is also data that is unstructured and exist in many different systems. For example, the case worker may need to generate a report on the average monthly payment for a life insurance for a certain group (e.g. based on age and ***). Other data can be meta data related to a customer, such as name or birth date.
This means the case management system needs to also support data analytics in form of Mashups composed of data from different sources. Here, it makes sense to rely on the new linked data standard.
People
Although this is the last item, it is one of the most important ones. People are involved in case management processes as we have described in the first figure. Additionally, we have also other stakeholders, such as customers that can be explicitly represented in the case.
Similarly to a case, business assets or activities, people in a case have also a lifecycle. For instance, they may be at the moment working on the case, be on sick leave or have left the company. If we consider more sophisticated case worker management (e.g. delegation of activities) then there are more states in their lifecycle (cf. [7]). Case management systems can help to efficiently and effectively schedule people to cases, activities or business assets.
Customers may also have a special lifecycle. This lifecycle can be very similar to the events in the life of the customer. For example, a customer may be married, divorced or has children. Depending on these events, certain actions might be required (e.g. health insurance for children).
Conclusion
Case Management enables flexible dynamic evolving processes centered around business assets. It allows a more flexible, but structured way to deal with this type of processes and with business assets. The stakeholders of a case, most notably the case worker, have a better overview what has been done, what is going on and what can be done next. This is mostly due to the structured and transparent way to model business assets, activities and rules governing them. They do not need check every time every system for business assets or data. Case workers or knowledge workers can work in more innovative and creative ways to solve a case. A case management system can help them to deal with them in a consistent way. This leads to reduced cost, improved delivery of service and has the potential to generate new ways of revenue previously locked in enterprise silos. Finally, case management systems can be used to capture dynamic evolving processes and improve the way they handle business assets.
We described how cases can be modeled to describe these kinds of processes and business assets. Some of these elements may become part of the Case Management Process Modeling (CMPM) – An Introduction.
What is next?
In the next blog entry, I will describe different system architectures for case management. This is relevant for Enterprise Architects, Solution Architects and Developers. I plan further blog entries on research challenges for case management.
Acknowledgements
This work results from the collaboration between SAP Research and the SCORE group at LORIA-INRIA-CNRS of the Université de Lorraine, Nancy, France.
References/Further Reading
[1] Olding, E. & Rozwell, C., Expand Your BPM Horizons by Exploring Unstructured Processes, G00172387, Gartner, 2009
[2] K. Bhattacharya, N. S. Caswell, S. Kumaran, A. Nigam, and F.Y. Wu. "Artifact-centered operational modeling: Lessons from customer engagements." IBM Systems Journal, 46(4):703- 721, 2007
[3] Franke, Jörn: Coordination of Distributed Activities in Dynamic Situations. The Case of Inter-organizational Crisis Management, PhD Thesis (Computer Science), to be published, LORIA-INRIA-CNRS, Université de Nancy/Université Henri Poincaré, France, 2011.
[4] Becker, Jörg; Michael Rosemann; von Uthmann, Christoph: Guidelines of Business Process Modeling, Business Process Management, 2000.
[5] de Man, Henk: Case Management: A Review of Modeling Approaches, BPTrends, January, 2009.
[6] Reijers, H.A.; Rigter, J.H.M.; van der Aalst, W.M.P.: The Case Handling Case, International Journal of Cooperative Information Systems, Vol. 12, No. 3, p. 365-391, 2003.
[7] Gaaloul, Khaled: A Secure Framework for Dynamic Task Delegation in Workflow Management Systems, PhD Thesis (Computer Science), LORIA-INRIA-CNRS, Université de Nancy/Université Henri Poincaré, France, 2010.
2 Comments
