Frank's Blog

Production Case Management 

Motivation


During the last decade, Business Process Management (BPM) has gained lasting acceptance as a discipline for modeling, executing, and monitoring business processes. Especially in the area of structured and repeated work, a high level of standardization and automation can lead to high gains in profits. Nowadays, however, BPM is often extended to areas of (partly) unstructured work. Our experience shows that—depending on the type of company—around 50-70 per cent of all processes are not well structured and cannot easily be modeled in standard notations as BPMN. Nevertheless, since in many companies these processes also represent mission-critical core processes, there is a high interest in gaining the BPM advantages as done for structured workflows.

Traditionally, the area of unstructured work is investigated in the field of Case Management. Case Management can be split into two different kinds: Adaptive Case Management (ACM) and Production Case Management (PCM), see Keith Svenson's blog. ACM focuses on unstructured work, where the activities are tied together at runtime via a central case document. Production Case Management, in contrast, focuses on pre-defined processes that typically only represent so-called ”happy paths”. While the former one has been investigated in depth during the last years, the latter one is not yet well investigated. Based on strong demands from our customers, we developed a certain kind of Production Case Management.

The idea is based on our experience that the business departments of companies have difficulties modeling processes that are not strongly structured. This is especially difficult, as the industry-standard BPMN 2.0 does not support the modeling of Case Management besides very basic concepts like the Ad-Hoc Sub Process. What can easily be captured by business departments, however, are so called ”happy paths” or 80 per cent process diagrams. These diagrams can also be easily represented in BPMN 2.0.

A student of mine, Jan Oehlert, investigated the idea of providing a framework that is able to combine a set of these ”happy path” diagrams and merge them together to provide a superset of the state transitions that are contained within the single diagrams. This raises several research questions, such as analyzing the ”merged” process diagrams for correctness, so that they can be executed correctly. It raises the question of how to integrate documents (data models) into the process diagrams. It raises the question of how to integrate additional state transitions that should explicitly not be modeled in a process diagram. It also raises questions about best-practices how BPMN 2.0 can be employed to model the set of diagrams and data models required.

Example


We would like to motivate our research with a simple example. Production Case Management is best applied on businesses with semi-structured business processes that are difficult to capture in a single diagram. The approach is most fitting, when there exist many variants with many instances of the business processes. One example are the back-office processes of large travel agencies that handle complaints from agencies and customers. Another, more simplified example, is a classical sales process.



As shown in the figure above, a ”happy path” sales process is made up of only two sequential activities, ”Create Offer” and ”Approve” offer executed by different roles. Attached to the process is a business (data) object that runs through different states. Since it is convenient for many business people to describe such a happy path diagram, it could easily be captured and agreed upon. Nevertheless, in most case already a huge amount of instances (cases) is handled by this simple business process diagram.

The first part of a process that needs to be defined in order to be executed via a PCMS is the process diagram or, to stress the core idea of our framework, multiple process diagrams. This approach may sound like traditional BPM but, in contrary to it, the process diagrams in PCM do not represent strictly to be followed execution paths. Therefore the diagrams are not required to be complete or need to include every possible execution step. They aim to be what we call ”80 per cent diagrams”, showing only the most likely paths and leaving out those that are not expected to appear very often. We also present the idea of leaving out ”every time possible” activities or events and placing them into separate diagrams instead. Once all diagrams of a process are merged together, the functionality of those separately modeled activities or events will be available without expanding other diagrams. In conclusion, process diagrams in PCM act more as supporting guidelines for the knowledge worker than as restrictive execution paths. We aim to keep them simple and comprehensible.
For instance, additional paths, either extensions or variants, are then simply modeled in different diagrams belonging to the same business process.



An example is shown in the figure above. Corresponding to the BPMN 2 standard, both activities ”Create Offer” and ”Approve Offer” are re-using the activities found in the first diagram via call behavior. Please note that an additional task ”Insert Technical Details”, executed by a different role, together with an additional state of the business object has been added.

In the second step of modeling processes for PCM, we extend our process diagrams by process data. As we have learned from numerous customer projects, there is typically one central data object, containing all case-relevant data (with arbitrary complex structures). We define this data object with its attributes in a separate Business Object Diagram (BOD) and use the BPMN node ”Data Object” to represent it in the earlier or simultaneously created process diagrams. The data model uses to grow whilst the modeling of the process diagrams as the need for further attributes is discovered during this phase. The BPMN node ”Data Object” can carry a state, what we make use of to define the different states a case can be in.

Examples of data objects have already been given in the examples. We assume our data object ”Offer” to only have three attributes ”Creator”, ”Price”, and ”Approved” for highlighting the principle.

From its instantiating to its termination, a case runs through a number of different states, typically like ”new”, ”in process” and ”closed”. In order to keep our framework as flexible as possible, we do not limit the number of potential case states to a pre-defined set. We rather allow the user to self-define them by placing data object nodes in a specific state into the process diagrams and associating them with sequence flows. Whenever a certain sequence flow is followed at runtime, the case is meant to take over the state which is carried by the data object connected to this sequence flow, denoted as case state transition. Later on we will introduce the concept of initial and final states to distinguish the beginning and the ending of the business processes and the individual start and end events found in the process diagrams.



States are also used to link different process diagrams together. An example is shown in the figure above. This part of the process is available if the state of the data object is ”Approved”.

Once all process diagrams are defined and modeled soundly, a case state life cycle is created, consisting of states and state transitions. To provide even more flexibility to our framework, we also support additional state transitions that are not based on any process diagram but exist as further requirements. How those ”additional state transitions” are specified, e.g. by forms or a special type of diagram, is left to precise implementations.



For the execution of the business process consisting of multiple process di- agrams, all possible state transitions of the business object are merged into a single state-transition-graph, representing the Case State Lifecycle, shown in the figure above for the example. Solid lines represent state transitions derived from the process diagrams, whereas dotted lines represent additional state transitions not depicted in a diagram. Regarding the sales process, it should be possible to rework ”Approved” offers, as denoted by the dotted transitions.

If we teased you enough, you can get the full story in all its glory right here (Jan's Master Thesis). Sorry, German only.
[ view entry ] ( 3806 views ) permalink $star_image$star_image$star_image$star_image$star_image ( 3 / 2156 )

<<First <Back | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | Next> Last>>